[patch] abuse of strncpy

[Rob Landley]

On Friday 09 June 2006 4:10 pm, Mike Frysinger wrote:
> > Unless it's a weak symbol, it should stop on the first hit...
>
> the symbols dmalloc/efence/memory-debugging-libs override are all allowed
> to be overridden in glibc

And the ones that aren't are generally header defines we can #undef.

> > > > 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.
>
> and then what ?  complain to the glibc guys and watch as they tell us to
> plzdiekthx ?  add some ugly hack to our headers to try and work around it ?

Yeah, basically.

But first, we wait for an actual problem to manifest rather than wearing an 
ankle bracelet to keep the land sharks away.

> > > 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
> >
> > In current gcc, -fno-builtin-strlen finally _works_ (that's in a header),
> > and we're relying on it.
>
> gcc should work just fine with -fno-builtin flags

"should" and "do" for gcc are different things.

> glibc should prevent overriding of string funcs if you set
> __NO_STRING_INLINES before including string.h
>
> but really, if we just simply dont use the same names, we never have to
> worry about the specific-libc "features" helping us out ... inline string
> defines arent the only things glibc has macros for ...

Ain't gonna happen.

> -mike

Rob
-- 
Never bet against the cheap plastic solution.