>I'd like to apologize for that comment. I did not intend to offend anyone.
>
>I only like to point out that stdio in Solaris has some unique
>limitations - only 255 file handles can be opened in 32bit
>applications and only 65535 for 64bit applications, compared to glibc
>the libc stdio is slow and the whole source code is somewhat infested
>with complex code to maintain the backwards compatibility to old
>behaviour.
The 8 bit file descriptor limit was lifted in a recent Nevada build;
but because of compatibility constraints it needs to be lifted explicitly,
either on a per-FILE or a per-program basis.
The 64 bit implementation does not have a 65536 limit; it uses an
"int" and it can therefor support upto MAXINT filedescriptors.
(Which other Unix OS implementation even supports 65536 file descriptors
in a single process; last I looked Linux' limits were less generous;
in Solaris I have run tests with over one million open FILE *s with
a ditto number of file descriptors)
I have peaked at the glibc stdio code and I did not find it an easy
read either.
I'm not sure what you mean with "infested with backward compatibility";
there is not much in the way of backward compatibility which needs to
be maintained.
Binary compatibility, OTOH, is something we need to bend over backwards
for; it is fairly hairy as there's only so much data you can put in 16
bytes. None of that applies to 64 bit code which simply uses a bigger,
yet opaque structure.
(For some reason, standards tests require code which does:
FILE fp = fopen("foo", "r")[0];
to compile)
Casper
