Date: Wed, 27 Feb 2008 09:43:03 -0500 From: David Schultz <das@FreeBSD.ORG> To: John Baldwin <jhb@FreeBSD.ORG> Cc: arch@FreeBSD.ORG, Garrett Wollman <wollman@hergotha.csail.mit.edu> Subject: Re: Cleaning up FILE in stdio.. Message-ID: <20080227144303.GA79999@zim.MIT.EDU> In-Reply-To: <200802262355.16519.jhb@freebsd.org> References: <200802262251.m1QMp7bV021709@hergotha.csail.mit.edu> <200802262355.16519.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080227144303.GA79999>