Re: Cleaning up FILE in stdio..

On Wednesday 27 February 2008 01:54:46 pm Garrett Wollman wrote:
<<On Wed, 27 Feb 2008 11:34:04 -0500, John Baldwin <jhb@xxxxxxxxxxx> 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.

Ok. I was going based on our manpages, but I will happily use EMFILE instead
given this. I will commit the temp fix today so we can MFC it.

--
John Baldwin
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"