From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 15:33:56 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 8CA5D1065679; Wed, 27 Feb 2008 15:33:56 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5538C8FC20; Wed, 27 Feb 2008 15:33:55 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id m1RFXsKg007174; Wed, 27 Feb 2008 10:33:54 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 27 Feb 2008 10:33:54 -0500 (EST) Date: Wed, 27 Feb 2008 10:33:54 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Schultz In-Reply-To: <20080227144303.GA79999@zim.MIT.EDU> Message-ID: References: <200802262251.m1QMp7bV021709@hergotha.csail.mit.edu> <200802262355.16519.jhb@freebsd.org> <20080227144303.GA79999@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Reply-To: Daniel Eischen 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 15:33:56 -0000 On Wed, 27 Feb 2008, David Schultz wrote: > On Tue, Feb 26, 2008, John Baldwin wrote: >>> I think you have the right idea but this will break the ABI in a way >>> that can't be fudged with symbol versioning. > [...] >> 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. We could >> create a new versioned FILE struct (so long as we can recognize the existing >> FILE struct somehow) and have new fopen()/fdopen()/freopen() symbols that >> return the new struct but then all the stdio routines would have to check to >> see if the structure was an old structure explicitly and handle it >> appropriately if so. Rather gross. > > Symbol versioning also doesn't help the case where a FILE * gets > passed from an app that's using the new symbol to another library > that's using the old symbol, or vise versa. If you do wind up > breaking the ABI again, maybe it's worth it to add an explicit > version number in the FILE struct itself, so we never have to > worry about this again. If we are doing anything about this and modifying FILE, perhaps we should also think about hiding all the innards of FILE, except for the few fields that are required for the stdio macros. -- DE