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>