[Toybox] towards xzcat cleanup

[Rob Landley]

On 04/11/2013 01:28:05 AM, Isaac Dunham wrote:
> More of same.
> Actually, it's not quite the same:
> -use crc_init(xz_crc32_table,1) -- I guessed on this one based on a  
> match between
> magic constants, then tested it. First try was wrong, but this works.*
> (This is the sole difference in terms of actual _code_, as opposed to  
> cleaning up
> defines and the like--here, it adds 48 bytes to final size if xzcat  
> is the only toy,
> but drops 32 bytes if bzcat is also enabled...)
> -Move some crc64 code to where the comments are. This puts them near  
> the area where
> they're used.
> -Remove some relics of separate files (we had half a dozen "this file  
> is in the
> public domain" notices, a duplicate include, and used extern  
> declarations for
> functions in the samefile)

Applied.

> *I don't know C very well.  Really, I went through the first few  
> chapters of "Using
> Turbo C" and a couple other books of similar age,

By Herbert Schildt?

(Everybody makes fun of the guy because he wrote like the Hitchhiker's  
Guide to the Galaxy. "Although it contains much that is apocryphal, or  
at least wildly inaccurate..." But his "How to Program in Turbo C" was  
better and more complete than the other book I had access to ("From  
Basic to C", from my community college's library). And moving from DOS  
to Unix was way bigger a change than anything Schildt got wrong. (Fork!  
Signal handling! No more near/far pointers! Cooked tty mode! mknod!  
setuid vs seteuid vs setfsuid...))

People don't teach C these days. They teach C++, which is not C. (A  
swimming pool full of jello may be mostly water, but flailing around in  
it is not gonna teach you how to swim. It's different, less general  
purpose, less generally useful, and who thought doing that was a good  
idea?)

> and then picked up what I needed to get things building over the last  
> 4-5 years.

Best way. :)

(I've been meaning to do a C tutorial or podcasts or something forever.  
It's on the todo list...)

> TODO (what I can see, in no particular order):
> Switch from  void change_global_static_variable(void) functions to a  
> proper API.
> Use toybox crc more completely
> Take an axe to the ifdef forest
> Merge the xz_dec*_end functions (all three of them)

All sound good.

> Match comments to functions, rather than prototypes...

If you declare stuff in the right order you usually don't need a  
prototype in the same file as the function. I also merge functions that  
don't have a good reason to be separate, which generally allows more  
opportunities for simplification once the code's inline.

> Figure out if xz_dec_end can be called before deciding whether we had  
> an error
> (potentially dropping one function call)
> 
> Should I drop the __always_inline macros?

Yes. If we can't just substitute the functions inline, let the compiler  
make inlining decisions.

A good reason to have a function is that it's called from more than one  
place. But it raises the possibility of reorganizing the code so it's  
_not_ called from more than one place, thus allowing it to be inlined  
in the one and only place that calls it. The function itself isn't just  
common code, the various calls to it often are. The question is whether  
or not you can combine them.

I did some of that in the uuencode cleanup, I'll try to write that up.  
(Not right now, gotta get back to work...)

Rob