>Casper.Dik at Sun.COM wrote:
>> >Due to the 32-bit ABI's stdio file descriptor limit, an interposer is
>> >being used to F_DUPFD non-stdio file descriptors to 256 and above. This
>> >mitigates a problem with 3rd party modules and plugins that use
>> >fopen(3C), et al. streams in processes such as Apache HTTP Server that
>> >open a large number of file descriptors. Unfortunately, using the
>> >interposer causes failures when a child process (e.g. CGI program)
>> >subsequently invokes telnet(1). If telnet passed the correct nfds value
>> >to select(3C), that failure would be eliminated.
>> In build 39 of Nevada we provide a standard interposer,
>> /usr/lib/extendedFILE.so, which has a similar, but different property.
>Umpf... for the same reason we were thinking about making the
>stdio-replacement API in libast public since it it supports an almost
>unlimited number of stdio channels...
Note that /usr/lib/extendedFILE.so does *not* use F_DUPFD; it calls
enable_extended_FILE_stdio(-1, -1) which makes a gaurantee on behalf of
the application that it does not reference FILE._file and in return the
C Library allows for the use of file descriptors > 255.
The kernel and the C library conspire such that any use of a FILE._file
for FILE's opened with a file descriptor over 255 will cause the application
to die with SIGABRT.