Date: Fri, 16 Feb 2001 20:29:36 +1000 From: Stephen McKay <mckay@thehub.com.au> To: arch@freebsd.org Cc: mckay@thehub.com.au, Warner Losh <imp@harmony.village.org>, Bruce Evans <bde@zeta.org.au> Subject: Re: The whole libc thing. Message-ID: <200102161029.f1GATar23483@dungeon.home> In-Reply-To: <200102160804.f1G84qW25651@harmony.village.org> from Warner Losh at "Fri, 16 Feb 2001 08:04:51 %2B0000" References: <Pine.BSF.4.21.0102161801590.2563-100000@besplex.bde.org> <200102160804.f1G84qW25651@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm getting into this kinda late. It feels like people are rushing. There is every reason not to rush. Backward compatibility can be preserved and should be preserved, and if people rush, then it won't be preserved. Think back. This has all happened before, early in 1998 with errno. It was really only solved by switching from a.out to ELF and hence forcing the biggest major version bump in FreeBSD history. :-) For the few people who kept on with a.out, I added the ld.so hack which is still a controversial item even today. Hi David! The absolutely correct answer is to bump every version number of every library everywhere. You don't want to hear that, but it is the answer. Why? Because nearly all libraries know a few details about the internals of stdio, from getc() or putc() macros, because stdin and friends are in an array, or just from groveling around (dangerously) inside FILE structures. We don't track this internal knowledge with version numbers or anything. A given program demands a particular version of libc, and all other libraries just blindly assume that whatever version of stdio they were compiled with will be binary compatible with the libc that turned up in the dynamic link stage. Recent changes have broken that assumption. But given that people want to avoid bumping all versions, and hence want to keep stdio binary compatibility despite substantial changes, we turn our minds to hacks. On Friday, 16th February 2001, Warner Losh wrote: >In message <Pine.BSF.4.21.0102161801590.2563-100000@besplex.bde.org> Bruce Evans writes: >: On Thu, 15 Feb 2001, Brian F. Feldman wrote: >: >: > My proposition wouldn't break any binary compatibility because it would >: > keep the FILE structure size the same. >: >: This isn't sufficient. fileno() and getc() used to be macros and/or >: inline functions that knew about the internals of the struct. > >Right. That's why I didn't move things around at all in the end. Any field you change must be a field that was never manipulated by a macro, and to be super nice, was never a "cool" thing for an over-friendly user to manipulate. "_up" seems reasonable from this point of view. >: > The actual contents are _not_ allowed to >: > be known outside of libc, so anything that gets it wrong after this change > >: > deserves to break in many horrible ways. We don't need a hash lookup >: > because there is already a _very_ seldom-used field, _up, which can be >: > absorbed for this purpose. I initially thought _cookie was better, but >: >: Your patch works because (hopefully) the field is so seldom used that it >: wasn't used by the old macros. > >I don't think that _up is used in macros back to 3.2. Further back >than that is not relevant since we start running out of the ELF world >and 3.x wasn't stable until 3.2. We should be concerned about binaries back to 3.0 (and rev 1.20 of stdio.h) to pick up the earliest ELF binaries. I fully expect all my old binaries to run after whatever hack we make here. Rev 1.20 isn't much different from the latest release (4.2) anyway, so if we want to support any 4.2 users, it shouldn't be too hard to support all ELF users. In rev 1.20, getc and putc were macros, more complicated if threading was involved. Other than that, you have the the __sF array to deal with and the need to keep pretty much everything at the same offset. But this is still hackery. The real answer is to bump all revisions. At the same time, we could make FILE opaque, and deal with the few programs that break because they meddle with FILE internals. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102161029.f1GATar23483>