Disabling inlining entirely saves 400+ bytes...

[Rob Landley]

On Tuesday 20 June 2006 6:01 pm, Aurelien Jacobs wrote:
> > Nothing else in busybox uses it for good reason,
>
> Then you can s/inline// in all other files of busybox...

Localized ugliness is an improvement over global ugliness.  I'm willing to 
make exceptions if there's a good reason and a big comment.

> > and the unlzma code has
> > numerous design flaws starting with "no way for the file command to
> > identify an unlzma file"
>
> Please be fair. This is not a flow of the unlzma code. It's a flow of
> the lzma bitstream. I agree it's bad. But I can't afford promoting a new
> incompatible bitstream format.

True.  Flaw in the lzma file format, and I agree it's not up to us to change 
it.

> > and continuing through "rangecoder.h is an abomination, don't
> > put functions in .h files
>
> Rename it to .c if you like. But it have to be #included in
> decompress_unlzma.c or it's content copied into decompress_unlzma.c.
> You can't compile inline functions in a .o and use them from another
> .c file !

Copying them into the start of decompress_unlzma.c would be good...  Done.

> > If the code really _needs_ to be inline, then expand it inline by hand.
>
> Waw ! Do you really prefer code duplication (up to 10 times), than clean
> inline functions ?

Having looked more closely at it, that's using ATTRIBUTE_ALWAYS_INLINE.  We 
were talking about the "inline" keyword which (like register) is a hint to a 
compiler that can generally do better without the hints.)

> BTW: a quick grep shows that inline is used in a lot of places. Lots of
> them are for purpose and are actually reducing size !

And a quick google shows I'm right.  Those two statements have about the same 
amount of specificity to them... :)

> Aurel

Rob
-- 
Never bet against the cheap plastic solution.