Skip site navigation (1)Skip section navigation (2)
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>