superfluous code in gunzip.c?

[David Daney]

Rob Landley wrote:
> On Friday 03 March 2006 1:15 pm, Robert P. J. Day wrote:
> 
>>  gunzip.c contains the snippets:
>>
>>#define GUNZIP_OPT_STDOUT   1
>>#define GUNZIP_OPT_FORCE    2
>>#define GUNZIP_OPT_TEST     4
>>#define GUNZIP_OPT_DECOMPRESS   8    <--- ??
>>
>>and
>>
>>opt = bb_getopt_ulflags(argc, argv, "cftd");   <--  "d" ??
>>
>>but i don't see where that "d" option is being processed and it's not
>>documented online.  dead code?
> 
> 
> You'll notice that the gnu versions of gzip and gunzip use the same kind of 
> trick busybox does, the two binaries are symlinked together.
> 
> If the name "gunzip" is given, it defaults to decompressing.  The -d option is 
> there so "gzip -d" can decompress, but since both gzip and gunzip have 
> exactly the same options you can give it to gunzip too (in which case it will 
> be ignored).  Some scripts, for whatever reason, do this.  (You'd think the 
> FSF would have put in a corresponding "Compress when called as gunzip" 
> command line option.  As far as I can tell, you'd be wrong.)
> 
> So having -d accepted but ignored by our gunzip makes some (arguably broken) 
> scripts happy, at the cost of one byte.  No point in adding it to the usage, 
> since it doesn't do anything.

If both programs have exactly the same options, then the getopt flags 
string will (should) be exactly the same.  Modern GCC/Binutils will 
combine the identical strings.  So removing the "d" instead of saving 
one byte would really increase the size, because the strings could no 
longer be shared.

So there may be savings to be had by looking at all getopt specification 
strings for all applets and reordering the contents to see if sharing is 
possible.

David Daney