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

[Bernhard Fischer]

On Thu, May 04, 2006 at 05:24:58PM -0400, Rob Landley wrote:
>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.)

I don't know, but i try to write C code for busybox. YMMV :P

>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.

This is not a fix but breaks the compilation for non-gcc compiles.

Can we _discuss_ how to fix this properly?


This optimization helps at least with gcc which is what most people will
use, probably.
I suggested above that we don't rely on the preprocessor but fix the
applets proper to use bb_strlen. This would IMO be a clean solution
which is safe and trivial.

Thoughts?

>
>I need to look through the bug generator and close some of these out...
>
>Rob
>-- 
>Never bet against the cheap plastic solution.
>