`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