[BusyBox] Re: [PATCH] Re: Sigh... this time i attached the file (bunzip-4.c)

[Manuel Novoa III]

Rob,

On Wed, Oct 22, 2003 at 05:23:16AM -0500, Rob Landley wrote:
> I did a couple cleanups that shouldn't affect functionality, but should make 
> it easier to read.  (Famous last words.)  The one I'm not quite sure about is 
> how the assembly works out turning an if(--x) into if(x--)...  that might 
> wind up being one extra instruction and slightly slower, I'm not sure.  (If 
> so, it's easily revertible.  It's just that when trying to detect a run 
> length of 3, counting down from 3 makes more sense than counting down from 4.  
> But it's not worth taking a speed or size hit...)

It does make a difference.  With "if(--x)", we just decrement x and then
jump based on the setting of the zero flag.  On the other hand, for
"if(x--)" we have to do an extra test on the value of x.  gcc generates
something similar to "if (--x == -1)" which decrements x, compares the
new value of x to -1, and then jumps based on the result.  The speed
difference was slight but observable.

> #warning should probably be "ssize_t read_bunzip(bunzip_data *,void *,size_t)"
> 
> No, it shouldn't.  This is not an offset into a file, this is the size of a 

I'm not sure why you're talking about file offsets here.  There isn't
really a connection between size_t and offset_t.  size_t is defined as
the unsigned integer type returned by the sizeof operator.

> memory buffer.  A platform that can index a block of memory larger than its 
> integer size is _badly_designed_.  We shouldn't need funky typedefs designed 
> to disguise the fact that ancient HP mainframes, which did all math as binary 
> coded decimal, also had to sacrifice a live chicken to access memory.  So I 
> say "int" is correct.
> 
> Feel free to disagree with this, but I'd like to hear the rationale. :)

I like consistency (principle of least surprise) and so tend to think
that the return type and args should mirror those of read() here.  But
I'd agree that accepting a size_t and returning a ssize_t is a weakness
in the standards.

Of course, the analogy with read() does break down in another respect.
Because read_bunzip() can read and buffer more than it needs, you might
have unused data remaining in the bunzip buffer if there is data
trailing the compressed block.  That is definitely an issue if you want
to treat this as a "black box".

Manuel