glitch with strlen [was: Re: Shells in 1.1.2]

[Rob Landley]

On Thursday 04 May 2006 2:25 pm, Bernhard Fischer wrote:
> On Thu, May 04, 2006 at 07:54:28PM +0200, Bernhard Fischer wrote:
> >On Thu, May 04, 2006 at 01:02:43PM -0400, Joe Shaw wrote:
> >>ok, the default config worked fine, so i guess it's my config...i will
> >>put below
> >>i'm using gcc 4.1
> >>my config will not work with either of the 4 shells
> >>running tty gave me "/dev/pts/1"
> >>i just realized i'm talking to the rob landley that wrote "How to use
> >>initramfs"
> >>thank you for that article sir, very useful
> >>
> >>ok, now my config
> >>joe
> >
> >Sounds like
> >http://busybox.net/bugs/view.php?id=847
> >
> >Please confirm if the patch there makes it behave for you, conceptually.
>
> The patch does fix it for me, without any size changes for the legacy
> mode of compiling the source files one-by-one.
>
> I'm not entirely sure how to fix this in a compiler agnostic way unless
> i do away with the #undef and adjust all users to use bb_strlen
> directly instead of relying on the preprocessor to fix the affected
> applets up.
>
> Thoughts?

We only need bb_strlen() on gcc anyway, since other compilers may not force 
inline strlen() in the first place.  But we're not compiler agnostic, and 
last I checked we weren't even pretending to be.  (Platform, yes.  Compiler, 
no.)

Sigh.  bb_strlen() always struck me as a marginal optimization.  The 
complexity is _almost_ worth it, but it keeps breaking.  I remember 
complaining when the #undef plus #include "libbb.h" in the middle of the file 
went in.  UGLY...

Alright, I just checked in a fix.  It's not a non-ugly fix, but it's at least 
less ugly than what was there.

I need to look through the bug generator and close some of these out...

Rob
-- 
Never bet against the cheap plastic solution.