`Hiding' libc symbols

[Jacques A. Vidrine]

On Tue, May 06, 2003 at 05:14:28PM +0200, Harti Brandt wrote:
> I have checked with the ISO-C draft I have around here. From a principal
> point of view, we are allowed to disable the redefinition of C-library
> functions. The question is, what does it help us and what do we loose:
> 
> It helps us to catch one particular kind of bugs in 3rd party software,
> where the software has a buggy implementation (in the context of our own
> implementation) of a standard function. This also rules actually non-buggy
> implementations of functions that adhere to newer standards than our own
> implementations. This means that in order to actually help we have to go
> through each instance of a port redefining a libc function and decide,
> whether it is buggy, the same as our implementation or simply more
> featureful and whether it is compatible with our implementation.
> 
> We loose the ability to do certain well known tricks (which have worked
> since C was invented), most of which help in debugging (f.e. replacing
> malloc or str* for range checking) and we make the porting of several
> software packages to FreeBSD actually harder.

For these reasons and others, I cannot support any attempt to make
it impossible for a programmer to define his/her own symbols that
conflict with the [foo] Standard.

Or stated more agressively, the day the FreeBSD toolchain refuses
to allow me to define my own version of strlcpy _for use by my
application_ is the day I find another development platform.

Tools, not policy.

If I can create code to override the internal libc strlcpy, too,
that's just a plus.  (Note we have this today even with `hidden'
symbols.)

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