`Hiding' libc symbols

[Harti Brandt]

On Tue, 6 May 2003, Jacques A. Vidrine wrote:

JAV>On Tue, May 06, 2003 at 05:14:28PM +0200, Harti Brandt wrote:
JAV>> I have checked with the ISO-C draft I have around here. From a principal
JAV>> point of view, we are allowed to disable the redefinition of C-library
JAV>> functions. The question is, what does it help us and what do we loose:
JAV>>
JAV>> It helps us to catch one particular kind of bugs in 3rd party software,
JAV>> where the software has a buggy implementation (in the context of our own
JAV>> implementation) of a standard function. This also rules actually non-buggy
JAV>> implementations of functions that adhere to newer standards than our own
JAV>> implementations. This means that in order to actually help we have to go
JAV>> through each instance of a port redefining a libc function and decide,
JAV>> whether it is buggy, the same as our implementation or simply more
JAV>> featureful and whether it is compatible with our implementation.
JAV>>
JAV>> We loose the ability to do certain well known tricks (which have worked
JAV>> since C was invented), most of which help in debugging (f.e. replacing
JAV>> malloc or str* for range checking) and we make the porting of several
JAV>> software packages to FreeBSD actually harder.
JAV>
JAV>For these reasons and others, I cannot support any attempt to make
JAV>it impossible for a programmer to define his/her own symbols that
JAV>conflict with the [foo] Standard.
JAV>
JAV>Or stated more agressively, the day the FreeBSD toolchain refuses
JAV>to allow me to define my own version of strlcpy _for use by my
JAV>application_ is the day I find another development platform.

So if you 'hide' all the libc symbols you will to exactly that. I can, of
course then define _malloc() instead of malloc(), but that is just another
case in the ever growing incompatibility between unices.

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

We have that if you happen to be a toolchain/libc expert, that knows, that
magically the linker does not do what it has done for decades - using the
first definition of a symbol for ALL following references and that you
have to prepend an underscore to work around this.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt at fokus.fraunhofer.de, harti at freebsd.org