From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 18:30:39 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2B3D1065679 for ; Wed, 27 Feb 2008 18:30:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 6E7068FC28 for ; Wed, 27 Feb 2008 18:30:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 233599874-1834499 for multiple; Wed, 27 Feb 2008 13:28:15 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m1RITrOi035092; Wed, 27 Feb 2008 13:30:10 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Peter Jeremy Date: Wed, 27 Feb 2008 11:38:33 -0500 User-Agent: KMail/1.9.7 References: <200802262251.m1QMp7bV021709@hergotha.csail.mit.edu> <200802262355.16519.jhb@freebsd.org> <20080227065925.GK83599@server.vk2pj.dyndns.org> In-Reply-To: <20080227065925.GK83599@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802271138.33979.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 27 Feb 2008 13:30:10 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/6010/Wed Feb 27 07:54:14 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org, Garrett Wollman Subject: Re: Cleaning up FILE in stdio.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 18:30:39 -0000 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