[BusyBox] [patch] hopefully my last bunzip2 patch.

[Rob Landley]

Okay, good news and bad news.

I moved the output file handling into uncompressStream.  This means there's no 
hidden length limitations in write_bunzip_data path, no unnecessary copying 
of data when decompressing to memory, write_bunzip_data always uses the same 
code path, and start_bunzip doesn't allocate an output buffer when one isn't 
necessary.

The bad news is this added another 80 bytes (it's now 6920 bytes total), and I 
seem to have screwed up the write() path enough to counteract Manuel's speed 
increase in the read() path. :(

The size increase is mostly due to all the state checkpointing to make 
write_bunzip_data interruptible in the middle of loops.  (Before the 
write-to-memory strategy was to overshoot into the output buffer and then 
memcpy the data out into the final buffer, memcpying any extra back to the 
start of the output buffer.  Yes, this sucked.)

The speed decrease I dunno about.  I'll leave it up to you guys as to whether 
or not this patch is salvageable.  On the other hand, there are situations 
where "write to memory" mode that's in CVS right now won't work (it'll go 
"bang" if you ask for too much data at once), and I'm not sure it EVER gets 
the CRC handling right.

Manuel: do you want to try to clean up the write() function here the way you 
did read()?  Also, I applied your patch by hand and then deleted any hunks 
that contained only whitespace changes, so if I screwed something up please 
tell me.  Query about one thing:
1)	if (((unsigned)nextSym) <= SYMBOL_RUNB) { /* RUNA or RUNB */
Why is this cast to unsigned?  It's set from permute[], can anything in that 
be negative?

I'm going to walk away from this code for a while now.  Not only is my to-do 
list empty, but I strongly suspect I've stopped actually improving it.

Off to tackle the compression side of things...

Rob

P.S. I just notice my patch stomps the stubs Eric added.  Oh well.  That's the 
least of its problems.  I attach it so people can see what I did in case it 
turns out ot be useful.  It slows stuff down and makes it bigger, so I'm not 
exactly pushing it for inclusion...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out.patch
Type: text/x-diff
Size: 11926 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20031018/3a521f87/attachment.bin