From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 05:15:01 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 18ECE106566B for ; Wed, 27 Feb 2008 05:15:01 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id C080E13C448 for ; Wed, 27 Feb 2008 05:15:00 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.13.8/8.13.8) with ESMTP id m1R5ExSa024047; Wed, 27 Feb 2008 00:14:59 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.13.8/8.13.8/Submit) id m1R5ExDe024046; Wed, 27 Feb 2008 00:14:59 -0500 (EST) (envelope-from wollman) Date: Wed, 27 Feb 2008 00:14:59 -0500 (EST) From: Garrett Wollman Message-Id: <200802270514.m1R5ExDe024046@hergotha.csail.mit.edu> To: deischen@freebsd.org In-Reply-To: References: <200802262251.m1QMp7bV021709@hergotha.csail.mit.edu> Organization: None X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 27 Feb 2008 00:14:59 -0500 (EST) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on hergotha.csail.mit.edu Cc: arch@freebsd.org 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 05:15:01 -0000 In article , Daniel Eischen writes: >> [I 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. > >Well, you can if you add compat symbols for all functions with FILE >as an argument. In every library, including hundreds of third-party libraries that pass FILE * arguments? I don't think so. What would work, although it would be extra pain, would be to extend the structure. It would be necessary to keep compatibility members of the structure, in their old locations, and update them to reflect state changes appropriately. If the only thing that will change is the width of _file, then that's probably a workable approach, since it doesn't break anything that wasn't already broken in the presence of FD 65536 anyway. Applications aren't permitted to store objects of type FILE, only FILE *, so this should be safe. -GAWollman