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