Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl

[Michael Koch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Dienstag, 11. Mai 2004 22:36 schrieb Steven Augart:
> Michael Koch wrote:
> > Which leads us to the discussion again what type a file
> > descriptor should have. Is an int (4 byte) enought for 64 bit
> > archs ? What about 128 bit archs in the future ? From the last
> > discussions fd should be at least long when. I know that GNU
> > classpath currently uses int but when we change it we can try to
> > do it right.
>
> Yes, an int is plenty of space.  It will always be plenty of space
> unless you plan to be opening more than 2^31 files (and that
> exceeds the limits of every Unix-like system that i know of).
>
> I should caution here that I don't have a copy of the POSIX spec.
> However, the manual page for open(2) on Linux says:
>
>         The  open() system call is used to convert a pathname into
>         a file descriptor (a small, non-negative integer  for  use
>         in  subsequent  I/O  as with read, write, etc.).  When the
>         call is successful, the file descriptor returned  will  be
>         the lowest file descriptor not currently open for the pro-
> -------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^­
>         cess.
>
> This guarantee is part of historical Unix semantics
> for open() -- there is still code around that (for example) closes
> file descriptor 0 (standard input) and then opens some other file,
> expecting that any successful open will assign descriptor 0 to
> the opened file.
>
> So, if open() ever stopped handing out the lowest descriptor
> it could, existing Unix code would break.

What if someone wants to port GNU classpath to an Operating System 
with totally different semantics like Windows ?


Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAoT4FWSOgCCdjSDsRAh9KAJ9dTcmLutgZ2J15tDQNdgb766No4QCfb+ls
eD0Jn1YYAA82ImQynrzpUiQ=
=i97K
-----END PGP SIGNATURE-----