ports/172332: [exp-run] Expanding stdio's internal file descriptors from short to int
John Baldwin
jhb at FreeBSD.org
Thu Oct 4 18:50:12 UTC 2012
>Number: 172332
>Category: ports
>Synopsis: [exp-run] Expanding stdio's internal file descriptors from short to int
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Thu Oct 04 18:50:10 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: John Baldwin
>Release: HEAD
>Organization:
>Environment:
>Description:
On Friday, September 28, 2012 6:47:39 pm John Baldwin wrote:
> Four years or so ago I cleaned up some of the stdio internals as fallout from
> running into problems with stdio using a short instead of an int to hold file
> descriptors. Back then I got sidetracked with attempting to make FILE opaque
> and ended up never getting around to bumping _file from a short to an int. I
> recently ran back into the SHRT_MAX limit at work again and came up with a
> patch to fix this.
>
> To preserve the ABI, it is necessary to leave the existing short _file in
> place and add a new int _file to the end of the FILE structure. Also, for old
> applications, the old _file (_ofile in the patch) must still be valid. The
> approach I have taken is to bump the symbol version for routines that create
> FILE objects with a non-fake _file (fopen, fdopen, and freopen). The old
> FBSD_1.0 variants still fail if an fd is greater than SHRT_MAX (and thus
> cannot be safely stored in _ofile). The new FBSD_1.3 variants assign to both
> _file and _ofile if the fd is less than SHRT_MAX. I also changed fileno()
> to no longer be an inline macro in <stdio.h> but to always be a function call
> going forward.
>
> If folks think this is ok, I'll hack up a modified version that hides _file
> from outside consumers (rename it to _nfile or some such) and send it for a
> ports-exp run before committing to make sure there aren't any 3rd party apps
> accessing _file directly.
I have a slightly modified version of my original patch that should hide _file
completely from any package builds. No ports should be directly accessing the
internals of FILE. They should be using things like fileno() instead. Can
you do an exp-run with a patched world to see if there are any such abusers?
The patch is MI, so I think just doing one architecture should be sufficient.
http://www.FreeBSD.org/~jhb/patches/stdio_file_exp.patch
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-ports-bugs
mailing list