`Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...)

[Jacques A. Vidrine]

On Thu, May 01, 2003 at 03:02:55PM +0100, Paul Richards wrote:
> On Wed, Apr 30, 2003 at 11:41:35AM -0500, Jacques A. Vidrine wrote:
> > [Trimmed cc:list;  moving to freebsd-arch]
> > 
> > 
> > First, has something been broken by making strlcpy/strlcat into a weak
> > reference?
> 
> Yes, deliberately overloading it from an application now no longer
> works.

Give me a break.  Good, it should not work by accident.  An
application might define strlcpy for its own use, but we should NEVER
use the application's strlcpy. [1]

> What really concerns me though, is that behaviour is only defined
> for 2 functions.

No, it is done for some 150+ functions.  If the technique didn't have
a certain distasteful side-effect when used en masse, I would push
for covering almost all of the other symbols libc exports.  (If an
application defines `strcpy', should we use that from within libc?)
But until a better technique arrives, I am happy to apply it a little
less liberally.

There are some specialized instances where it _does_ make sense to
override a function that libc utilizes.  malloc and free are one
example.  The socket-related functions might be another (for SOCKS
implementations).    The fact that we've `hidden' connect(2) et al
using this same technique for over two years without much impact on
the functioning of such applications is a pretty good indicator to
me that concerns in this area are unfounded.

> I think this should be backed out, as most people in this thread
> have pointed out, you've added a quirk to our C library to fix a
> poorly coded application and whichever way you look at it, that's
> not the right solution.
>
> The implementation of FreeBSD should be what's correct, we shouldn't
> fudge things to accomodate bad packages, fix the problem where the
> problem really exists.

Obviously, I don't see it the same way you do.  Calling the
application's strlcpy in order to implement some internal libc
function is not ``what's correct'', regardless of whether the
application is buggy or perfect.

Cheers,
-- 
Jacques Vidrine   . NTT/Verio SME      . FreeBSD UNIX       . Heimdal
nectar at celabo.org . jvidrine at verio.net . nectar at freebsd.org . nectar at kth.se

[1] I know.  Never say never.