[James Chacon <jmc%NetBSD.org@localhost>]
Also, this is only testing against SHRT_MAX so you really only get
16k of files.
What's SHRT_MAX got to do with a 16k limit? Do we have a machine
where
SHRT_MAX is only 16383? I thought C required it to be at least 32767.
[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]
I stared at the FILE struct for a bit and there's no buffer space
anywhere in this. If there had been a spare couple bytes somewhere
we could have split the int potentially and dealt with it that way.
No, even that would break the ABI. The problem is that fileno is a
macro by default and therefore older code can be expected to depend
on the current _file.
But that older code is already broken in the face of fds over 65535,
and maybe over 32767, so I see nothing wrong with leaving the current
_file's place in the binary structure as just the low bits of the fd,
with the rest stored elsewhere. (Personally, I'd just use an int
elsewhere and duplicate the low bits into the current slot for the
sake
of ABI compatability, making that low-bits duplicate write-only except
for legacy users of fileno().)