Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Feb 2008 11:38:33 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        Peter Jeremy <peterjeremy@optushome.com.au>
Cc:        arch@freebsd.org, Garrett Wollman <wollman@hergotha.csail.mit.edu>
Subject:   Re: Cleaning up FILE in stdio..
Message-ID:  <200802271138.33979.jhb@freebsd.org>
In-Reply-To: <20080227065925.GK83599@server.vk2pj.dyndns.org>
References:  <200802262251.m1QMp7bV021709@hergotha.csail.mit.edu> <200802262355.16519.jhb@freebsd.org> <20080227065925.GK83599@server.vk2pj.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 27 February 2008 01:59:25 am Peter Jeremy wrote:
> On Tue, Feb 26, 2008 at 11:55:16PM -0500, John Baldwin wrote:
> >Yes, I discovered the macros today while working on my fd as short problem.  
> 
> Macros and __inline functions mean that a significant proportion of
> software compiled on FreeBSD has the existing definition of FILE
> compiled into it.
> 
> >However, I can't fix the fact that our stdio can't handle fd's > SHRT_MAX 
> >(again, glibc handles this just fine) w/o making a royal mess.
> 
> I don't think a versioned FILE is practical so we are stuck with a
> 16-bit _file for the immediate future.
> 
> >What I've gone with instead to fix the SHRT_MAX problem is to change 
> >fopen/fdopen/freopen to fail to use fd's > SHRT_MAX with an error.
> 
> You could change _file from 'short' to 'unsigned short' without breaking
> the ABI - this would allow either 65535 or 65536 file descriptors (I'm
> not sure whether _file == -1 is special or not).  This would postpone
> the problem for some time.

-1 is used a lot in the stdio code for file's not backed by an fd.  My problem 
though is that this doesn't help with existing binaries that are already 
compiled (which is what I have to deal with).  Had fileno() not been inlined 
I would have been ok, but that's pretty much done for me as far as my current 
problem on 6.x.  Had I just been able to change FILE * and not had inlines, 
then a new fopen would have worked fine in my case.

> My suggestion would be:
> Now:
> a) change _file to 'unsigned short' and add checks as proposed
> b) merge __sFILEX into FILE
> c) Remove the macros and inlines that poke around inside FILE
> d) Note that directly accessing FILE innards is deprecated and
>    move the definition of struct __sFILE into libc/stdio/local.h

Yes, but also d2) tag all the fields that were previously exported and so they 
are not changed in the future.

> Once RELENG_8 is branched:
> e) Don asbestos underwear and re-arrange struct __sFILE to grow _file etc.

We can't do e) because thanks to symbol versioning, 8.x and 9.x will have 
libc.so.7, so a 7.0 binary will still use the brand new libc, so it has to 
preserve the ABI of the currently exported fields pretty much forever.  I do 
think we can get away with renaming '_file' to '_ofile' and adding a new 'int 
_file' at the bottom of the struct and making sure '_ofile' is always in sync 
(when possible, truncated when _file is too bug).

Also, I think we can do the new _file in HEAD for 8.0 w/o any worries.  I 
don't think waiting until 9.0 buys anything there.  Given that, I think I'd 
rather just patch the current stable branches to handle the edge case better 
and work on making _file an int in HEAD (with the ABI compat _ofile).

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802271138.33979.jhb>