Date: Wed, 27 Feb 2008 13:57:29 -0500 From: John Baldwin <jhb@freebsd.org> To: Garrett Wollman <wollman@freebsd.org> Cc: arch@freebsd.org Subject: Re: Cleaning up FILE in stdio.. Message-ID: <200802271357.29188.jhb@freebsd.org> In-Reply-To: <18373.45558.444085.196189@hergotha.csail.mit.edu> References: <200802262251.m1QMp7bV021709@hergotha.csail.mit.edu> <200802271134.04166.jhb@freebsd.org> <18373.45558.444085.196189@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 27 February 2008 01:54:46 pm Garrett Wollman wrote:
> <<On Wed, 27 Feb 2008 11:34:04 -0500, John Baldwin <jhb@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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802271357.29188.jhb>