Date: Tue, 26 Feb 2008 15:32:33 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Cleaning up FILE in stdio.. Message-ID: <Pine.GSO.4.64.0802261531160.9339@sea.ntplx.net> In-Reply-To: <200802261524.30384.jhb@FreeBSD.org> References: <200802261524.30384.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0802261531160.9339>