tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: short _file in stdio -> fd leak

On Mar 13, 2008, at 12:31 PM, der Mouse wrote:

[James Chacon <>]

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.

My math is bad at 1am :-)

[Joerg Sonnenberger <>]

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

fileno() isn't exactly legacy use. It's pretty well used.

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



Home | Main Index | Thread Index | Old Index