Re: short _file in stdio -> fd leak

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

[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().)

Or we could blow off ABI compatability.  We've done that before.

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               mouse%rodents.montreal.qc.ca@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B