Date: Thu, 1 May 2003 11:34:57 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: "Andrey A. Chernov" <ache@nagual.pp.ru> Cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) Message-ID: <Pine.GSO.4.10.10305011129010.11732-100000@pcnet1.pcnet.com> In-Reply-To: <20030501151458.GA54182@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 1 May 2003, Andrey A. Chernov wrote: > On Thu, May 01, 2003 at 09:53:45 -0500, Jacques A. Vidrine wrote: > > > > A libc consumer (getpwent.c): > > 587 namesize = _strlcpy(&keybuf[1], name, sizeof(keybuf)-1); > > IMHO, it is bad hack at whole, and all namespace.h tricks should be > removed. > > The reason is quite simple. Yes, you can save libc this way, but what > happens, if application linked, say, with libc AND libncurses (insert any > other system library here)? libc will be saved, but libncurses will not. > It means, to be logically, you need to replace strlcpy with _strlcpy in > ALL FreeBSD libraries. Better way is stop doing half-singing - > half-dancing and produce linker error when application attempts to replace > any function in standard namespace. It automatically makes impossible > broken binary-only packages. > > So, I vote for namespace.h removing (i.e. all _ tricks). Who with me? Wrong. We need _ tricks for threads libraries to work properly and was the reason it was added in the first place. BDE came up with the idea and it was reviewed by him. People developing and modifying libc need to be aware of the requirements of the threads libraries. Libc isn't in its own little world anymore; it has to play along nicely with others. Sure, you can debate strlcpy/strlcat if you want, but please don't remove things that need to be there (in [un-]namespace.h). -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10305011129010.11732-100000>