[PATCH] Re: glitch with strlen [was: Re: Shells in 1.1.2]
Rob Landley
rob at landley.net
Fri May 5 22:28:50 UTC 2006
On Friday 05 May 2006 5:51 pm, Bernhard Fischer wrote:
> >If -fno-builtin-strlen gives us the same general result as bb_strlen on
> > gcc 4.x, then the obvious thing to do is add a check_gcc for that and
> > yank bb_strlen entirely. It's a small enough optimization that gcc 3.x
> > can live without it.
>
> I didn't look, but perhaps someone knows if it is benefical to avoid
> most of @plt and instead use the internal func which in turn is the
> only one using the external ref?
*blink* *blink*
Ok, I need more caffeine. I don't know what you just said. I'm guessing @plt
is some internal gcc thing, or from spec somewhere, or something. By "the
internal func" I suspect you mean __builtin_strlen() which the recent patch
switched us to using. I'm guessing external ref is external reference but I
don't know what you mean by that, possibly the standard strlen() from posix?
Or perhaps this is some way of referring to the -fno-builtin-strlen command
line option?
Nope, still in the dark on this one. However, I will say that a compiler
switch to turn off an unwanted optimization makes more sense to me than
working around that optimization with #ifdefs in the source code.
Rob
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list