Cleaning up FILE in stdio..

[Garrett Wollman]

<<On Wed, 27 Feb 2008 11:34:04 -0500, John Baldwin <jhb at freebsd.org> said:

> I avoided EMFILE in all 3 cases as it struck me as being not really true (an 
> app would find the rlimit higher than the current fd for example).  Also, 
> EMFILE doesn't really make sense from fdopen() at all.  You've already opened 
> the fd, so you know you can't run out of fd's.

[EMFILE] is does not imply that you have run out of fds.  POSIX
says (for fdopen()):

The fdopen( ) function may fail if:
[EBADF]            The fildes argument is not a valid file descriptor.
[EINVAL]           The mode argument is not a valid mode.
[EMFILE]           {FOPEN_MAX} streams are currently open in the
                   calling process.
[EMFILE]           {STREAM_MAX} streams are currently open in the
                   calling process.
[ENOMEM]           Insufficient space to allocate a buffer.

My change to sysconf() causes {STREAM_MAX} to be clamped at
{SHRT_MAX}, so a user calling sysconf(_PC_STREAM_MAX) or
$(getconf STREAM_MAX) will see a different value from the resource
limit and understand that there is a limit (even if it's not quite on
the number of streams).

For fopen(), the errors are defined as follows:

"shall fail":
[EMFILE] {OPEN_MAX} file descriptors are currently open in the calling
process.
[ENFILE] The maximum allowable number of files is currently open in
the system.

"may fail":
[EINVAL] The value of the mode argument is not valid.
[EMFILE] {FOPEN_MAX} streams are currently open in the calling
process.
[EMFILE] {STREAM_MAX} streams are currently open in the calling
process.

The other possibility would be [EOVERFLOW], which is defined as:

[EOVERFLOW] The named file is a regular file and the size of the file
            cannot be represented correctly in an object of type off_t.

But I truly believe that [EMFILE] is the best option.

-GAWollman