`Hiding' libc symbols
John Baldwin
jhb at FreeBSD.org
Thu May 1 11:45:03 PDT 2003
On 01-May-2003 Jacques A. Vidrine wrote:
> On Thu, May 01, 2003 at 02:05:49PM -0400, John Baldwin wrote:
>> Agreed. Somebody just needs to sit down and fix the qpopper port and
>> then the argument for this change goes away and it can be reverted.
>
> qpopper is not the point. The qpopper port was fixed just a couple of
> hours after I made the commit to libc. (I had sent the qpopper patch
> to the port maintainer earlier.) Preventing the bogus behavior from
> ever happening again was the point.
>
> A lot of folks are focused on qpopper and strlcpy. I believe that
> the big picture is being missed. I moved this thread to freebsd-arch
> so that we could discuss how to hide all (or most, or non-standard)
> symbols in libc. Not so that we could argue about this particular
> commit.
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?
--
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
More information about the freebsd-arch
mailing list