Date: Tue, 09 Feb 1999 20:17:42 +0300 From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, dt@FreeBSD.ORG Subject: Re: cvs commit: src/include stdio.h src/lib/libc/stdio Makefile.inc fgetpos.c fseek.3 fseek.c fsetpos.c ftell.c Message-ID: <199902091717.UAA20795@arc.hq.cti.ru> In-Reply-To: Your message of "Wed, 10 Feb 1999 02:17:39 %2B1100." <199902091517.CAA16311@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> >However, there is a change I omitted that would, IMO, require a major > >version bump: addition of (not so) new errno values to sys_errlist. :-| > >As I understand, applications dynamically linked with old libc will be > >confused by a change of size of this array... > > No. The old code should use sys_nerr to avoid accessing beyond the end > of sys_errlist[], even if it is too crufty to use strerror(), etc. As I understand, sys_nerr don't help here. ld(1) relocate sys_errlist to some address while link the program, as well as any other symbol, and use its size stored in the "old" libc. So, larger sys_errlist from newer libc simple won't fit in the place relocated to it. The program will see new value of sys_nerr, though... Actually, I forgot details since I last looked. This issue is a bit different in a.out and elf. Apparently, for this reason NetBSD changed sys_errlist to be a pointer. A standard Terry's lecture "why dynamic linking with LGPL'ed library still don't make your program comply with LGPL" may be relevant here... Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902091717.UAA20795>