Re: Cleaning up FILE in stdio..
- From: Daniel Eischen <deischen@xxxxxxxxxxx>
- Date: Tue, 26 Feb 2008 15:32:33 -0500 (EST)
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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- References:
- Cleaning up FILE in stdio..
- From: John Baldwin
- Cleaning up FILE in stdio..
- Prev by Date: Cleaning up FILE in stdio..
- Next by Date: Re: cpuset and affinity implementation
- Previous by thread: Cleaning up FILE in stdio..
- Next by thread: Re: Cleaning up FILE in stdio..
- Index(es):
Relevant Pages
|