[patch] abuse of strncpy

Rob Landley rob at landley.net
Fri Jun 9 15:22:44 UTC 2006


On Thursday 08 June 2006 5:34 pm, Mike Frysinger wrote:
> > When?  When did we actually have namespace issues?  The bb_blah prefix
> > was added to fix a problem we weren't seeing.
>
> i was asking ... generally glibc declares such functions as weak (like the
> str* funcs) so that you can override them without build failures when you
> link statically
>
> i dont know if there is a hard rule about this though, so i'm not sure you
> can just override any old symbol provided by the libc

In theory library link order should do this for you.  If it _doesn't_, how 
does this chunk of Rules.mak accomplish anything useful?

ifeq ($(strip $(CONFIG_DMALLOC)),y)
    # For testing mem leaks with dmalloc
    CFLAGS+=-DDMALLOC
    LIBRARIES:=-ldmalloc
else
    ifeq ($(strip $(CONFIG_EFENCE)),y)
        LIBRARIES:=-lefence
    endif
endif

Unless it's a weak symbol, it should stop on the first hit...

> > As far as I can tell, the prefix started getting added everywhere when
> > the shared library went in
>
> *shrug* by not using the standard name, you're guaranteed gcc/glibc wont
> slip in its own version on you

If it does, it's a bug.  And we'll treat it as such when we find it.

> gcc has builtins that can be disabled if we add -fno-builtin, but i'm not
> sure it'll be so easy/sane to override things the libc throws at us via
> headers -mike

In current gcc, -fno-builtin-strlen finally _works_ (that's in a header), and 
we're relying on it.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list