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

[Bernhard Fischer]

On Fri, May 05, 2006 at 08:53:29AM -0500, Jason Schoon wrote:
>On 5/5/06, Bernhard Fischer <rep.nop at aon.at> wrote:
>>
>>
>>Proposed real fix:
>>apply attached busybox.fix_strlen.01.diff
>>and then replace all strlen() with bb_strlen() e.g. via
>>find ./ -name "*.c" -exec egrep --exclude='*xfuncs.c*' \
>>--exclude='*scripts/*' -Hl "[^_]strlen" {} \; | xargs \
>>sed -i -e "/[^_]strlen/s/strlen/bb_strlen/g"
>>
>>The end result is that it is even smaller for the .config provided by
>>Joe Shaw earlier in this thread and does what it's supposed to do:
>>
>>   text    data     bss     dec     hex filename
>>867078    7656  825676 1700410  19f23a ../bb.svn.oorig/busybox.landley
>>867062    7656  825676 1700394  19f22a busybox.strlen_ok.gcc-4.1
>>
>>objections or can i go and check this in early next week?
>
>
>I assume that if you go with this approach, we will no longer try to do
>anything with strlen() in the preprocessor or build process?  Thus, if a new

Exactly.

>applet came in which used strlen(), it would simply not be as optimized on
>GCC, but would still function perfectly fine?

Yes. I thought about a debug option which would
#defing strlen bb_strlen__is_to_be_used_here
as i suggested sometimes in 2005 for all the functions in libbb, but we
currently don't have this facility (although i think that it may be nice
to have -- as a debugging option, as said).
>
>In that case, I think this is a good approach.

Thanks for your comment.. cheers,