Re: fileno(tmpfile()) returns EBADF

[Roland McGrath]

> Sure, but there is *no* difference between doing so immediately and
> doing so upon demand...

Sure there is.  The basic requirement here is that the the OPEN_MAX limit
be enforced as specified, on the total of fopen+tmpfile + open and other
POSIX.1 calls (and probably some other ISO C call I am forgetting).  In our
case, that means the value from sysconf(_SC_OPEN_MAX), which is the soft
resource limit for RLIMIT_NOFILE.  Unless we change some of all of those
semantics, then setting your resource limit to a value low enough that you
have no free file descriptors when you call tmpfile must fail.
Furthermore, a value such that you have two free when you call tmpfile must
cause the second subsequent fopen/tmpfile/open/dup/etc call to fail with
EMFILE.  So the difference between doing so immediately and doing so upon
demand is that the call that creates the potential for the later demand
must immediately update some separate count of descriptors consumed for
limit purposes but not actually allocated.

I am in favor of further optimizing these things.  But for tmpfile I was
providing a quick fix for a problem holding up the smooth adoption of the
new ABI, so the simple and unoptimized solution today (actually day before
yesterday :) was what we needed, and that's all that should probably go
into libc-2.2.  The current libio code also does not circumvent the
int->pointer lookup for file descriptors (we're just using the generic
POSIX-compatible code).  That too could and should be better optimized for
the Hurd, but I am not worrying about that in 2.2, where we are already
pretty stable and going just for more stability.