`Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...)
Daniel Eischen
eischen at pcnet1.pcnet.com
Thu May 1 08:35:01 PDT 2003
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
More information about the freebsd-arch
mailing list