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