Date: Thu, 1 May 2003 14:10:27 -0500 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols Message-ID: <20030501191027.GA53801@madman.celabo.org> In-Reply-To: <XFMail.20030501144502.jhb@FreeBSD.org> References: <20030501182820.GA53641@madman.celabo.org> <XFMail.20030501144502.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 01, 2003 at 02:45:02PM -0400, John Baldwin wrote:
> It seems that many people don't think the symbols in libc need
> hiding. What is the reason to prevent a user from overriding the
> functions used by libc? malloc() and free() are an example you
> agree to, and I don't think we should hide things willy-nilly.
> There are many uses for overriding symbols in libc that I'm sure
> neither of us have thought of. Why artificially limit it?
Nothing prevents one from conciously overriding these parts of
libc. I'm merely trying to prevent it from happening accidently.
Hiding things willy-nilly is indeed not what we should do.
There are several reasonable approaches to determining what
to hide.
(a) Hide all symbols not explicitly defined in ISO C.
(b) Ditto, but raise the bar to POSIX.
(c) Hide all symbols, except those that are likely to
be candidates to be overridden. malloc/free seem
to be the only ones here.
The reason that it has been willy-nilly to this point is because we
have an imperfect mechanism. Why did I pick on strlcpy/strlcat? Well
obviously because of the subtle problem with qpopper, but also because
these are functions that are often implemented in portable code, right
or wrong that may be. (I would likey not have attempted to hide
strcpy if that would have been the issue.)
Static linking can make these conflicts become apparent, but if you
are dynamic linking --- as is usually the case --- these problems
stay dormant until they bite you on the ass. This is dangerous
behavior and IMHO we should remove the chance for such accidents where
possible. It causes no harm to do so.
I have now backed out the strlcpy/strlcat commit.
Huh, only now do I notice that NetBSD hid strlcpy/strlcat over a year
ago in their tree. :-)
Cheers,
--
Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal
nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501191027.GA53801>