[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