[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