Cleaning up FILE in stdio..
Daniel Eischen
deischen at freebsd.org
Tue Feb 26 20:32:35 UTC 2008
On Tue, 26 Feb 2008, John Baldwin wrote:
> Way back in the 4.x days we had a fiasco over changing the size of FILE
> (struct __sFILE) to add locking for multithreaded apps because
> the 'stdin', 'stdout', and 'stderr' symbols were direct references to the
> global array of FILE objects. The first fix was to move the locking fields
> into a private 'struct __sFILEX' to preserve the size of FILE. Later the
> stdin/out/err symbols were fixed to reference standalone pointers instead of
> the global array. Given that, I think at this point we can safely merge
> __sFILEX back into __sFILE w/o breaking anything. This is assuming that the
> contents and layout of FILE are not a public ABI (i.e. we malloc the things
> internally and consumers should just treat the pointer value as a cookie and
> not grub around in the internals). In addition to removing the __sFILEX
> stuff, I'd like to change the fd member of FILE to be an int so you can open
> more than 32k files via fopen(). Otherwise, if fopen() gets an fd that is >
> SHORT_MAX, it gets sign extended when the fd is passed to read(), close(),
> etc. and those calls fail with EBADF.
>
> Comments?
Try it and see if anything breaks?
--
DE
More information about the freebsd-arch
mailing list