Date: Tue, 21 Aug 2001 01:09:27 +1000 From: Stephen McKay <mckay@thehub.com.au> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: mckay@thehub.com.au, current@FreeBSD.org, Peter Wemm <peter@FreeBSD.org> Subject: Implications of stdio changes (was Re: cvs commit: src/include stdio.h src/lib/libc Makefilesrc/lib) Message-ID: <200108201509.f7KF9RV26692@dungeon.home> In-Reply-To: <Pine.SUN.3.91.1010814135736.3623B-100000@pcnet1.pcnet.com> from Daniel Eischen at "Tue, 14 Aug 2001 18:06:05 %2B0000" References: <XFMail.010814085834.jhb@FreeBSD.org> <Pine.SUN.3.91.1010814135736.3623B-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 14th August 2001, Daniel Eischen wrote: >> > So do we allow FILE to be extended only after bumping the library >> > version once (after 5.0-release)? And thereafter all extensions to >> > FILE do not need a version bump? >> >> We've already bumped libc for 5.x. Assuming this works ok, we shouldn't need >> any further bumps for extending FILE. > >True. I guess the real problem is the other libraries that reference >stdin, stdout, stderr. These need to be rebuilt with the new stdio.h >and libc in order to avoid any impact from future FILE changes. I might sound like the harbinger of doom, but you have to bump the major number on every library that uses stdio to solve the "FILE has changed size" problem. It's the same sort of problem that changing errno caused. That was "solved" by the switch to elf, which caused global recompilation. People are hoping to do this by just waiting. Eventually most libraries will experience a major version bump. Similarly, most useful programs will be recompiled (either against bumped libraries, or recompiled old ones). But some programs will not be recompiled, and will fail in mysterious ways. I often use really old binaries, so odds are it will happen to me. :-) To prevent old binaries from going bad, the libraries they link to must use the old version of stdio. Definite ideas of the offset in __sF of stdout and stderr are embeded in both the old programs, and the old libraries (and of course, the old version of stdio). If you recompile the libraries against the new stdio, you break the old binaries. The solution is to not do that. In short, when FILE changes size (and hence __sF offsets change), then every consumer(*) of stdio must be bumped. The recent __stdinp (and friends) addition prevents this problem happening again in the future, but does not solve the current problem of old binaries and old libraries knowing the internals of stdio. Stephen. (*) OK, technically only uses of "stdout" and "stderr" variables screw up when FILE changes size. Uses of macros (like getc variants that are sometimes macros) will screw up if offsets change, but that's easier to avoid. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108201509.f7KF9RV26692>