[Toybox] gunzip.c cleanup

[Rob Landley]

On 01/08/2018 07:27 PM, enh wrote:
> the tests were here but never merged:
> http://lists.landley.net/pipermail/toybox-landley.net/2017-April/008962.html

Yeah, it's in my todo heap. The problem is it's testing that gzip and
gunzip match, if both were doing "cat" it would pass. I'd like to test
at least some of the time against canned data. I was also mentally
comparing it against tests/files/bzcat where I have two archives with
different kinds of failures I wanted bunzip2 to catch. (The bunzip2
tests use the blkid files, which are coincidentally bzipped. For gzip
I'd have to add test data...)

Still, better starting point than what's currently there I suppose.
Applied...

(Then there's "can gzip recreate this file exactly", which is
fraught-ish because there's questions of dictionary flush timing in
there which aren't in the spec. It's nice to be able to recreate a
tarball with the same sha256 as other implementations, but how high a
priority is that? Hmmm... I wonder what busybox does there...)

> i did see the weird suffix addition stuff when i read the man page,
> but since it was (a) the first time i'd heard of it in 25 years and
> (b) disgusting, i thought i'd wait until someone actually needed it.
> 
> likewise the ignoring errors. that seemed like a bug rather than a
> feature until proven otherwise.

The "zcat README" acting like cat is an artifact of using gzread()
instead of inflate().

> but, yeah, i should have said so in TODO comments. (i thought i did
> comment the former, but that may have been lost in the toybox
> obfuscated c competition rewrite.)

I'm working towards merging the builtin inflate implementation and
promoting the command, but there's a filing issue where gzip wants to
reach over and do deflate (gzip -d) and zip also needs both. I can
either throw the shared plumbing in lib (which bunzip2 isn't) or I can
put them together in the same toys/* file (inflate and deflate both,
which is how ps.c and cp.c and such do it, but I like to keep source
files under 1000 lines when possible and ps.c is unavoidably way over
because it's got 5 commands in it, 2 of which are rather complicated...)

(I'm not worried about "tar" because that should shell out and pipe
through...)

I also hacked up "compress.c" to let me use different header signatures
(ala the zlib stuff used by git), and I'm kinda squinting at it to see
if there's a clean way to do that to gzip. I suspect zcat should
autodetect, but on the compression side... Hmmm.

(One of my post-1.0 goals is adding enough git support that repo can
'git clone' the source packages it wants to build, and I am NOT sticking
git plumbing in gzip.c...)

Rob