[Toybox] Style change for GLOBALS()
Rob Landley
rob at landley.net
Sun Aug 26 19:36:37 PDT 2018
On 08/22/2018 08:01 PM, Rob Landley wrote:
> I'm thinking of making it so argument variables populated by lib/args.c have the
> same name as the option (so "a#" has a corresponding 'long a') and changing the
> "one per line" to allow them to be grouped. Still a blank line between arguments
> and non-argument globals.
Since nobody objected for a few days, I'm advancing through:
grep --color=always 'TOY(.*".*[[:punct:]].*"' toys/*/*.c | head -n 170
Working my way back from the end and converting commands.
I should probably also redo the command optstring order (which is _kinda_
alphabetical but not consistently enforced?) on a few commands so that I can
group things like:
char *a, *b, *c;
long d, e;
char *f, *g;
into:
char *a, *b, *c, *f, *g;
long d, e;
But I have a second pass queued up to take advantage of the toys/pending/ipcs.c
trick of:
toys/pending/ipcs.c:#define flag(x) (toys.optflags & FLAG_ ## x)
toys/pending/ipcs.c: if (flag(u)) {
toys/pending/ipcs.c: if (flag(l)) {
toys/pending/ipcs.c: if (flag(t)) {
I.E. adding a #define FLAG(x) in toys.h and then convert most of the existing
if (toys.optflags&FLAG_blah) thingy();
to
if (FLAG(blah)) thingy();
(The reason I didn't before is toys.optflags&(FLAG_c|FLAG_b|FLAG_c)) has no
obvious macro simplification, but eh. FLAG(x) is the common case and the
compiler _might_ be smart enough for FLAG(a)|FLAG(b)|FLAG(c) to turn into
something sane? I've never worked out what C optimizers are really _for_, to be
honest...)
I should really spend some cycles on the test suite so I can run it as a
regression test when I do this sort of thing (which shouldn't change any
behavior, and if it does I broke stuff). That _is_ its main purpose...
Rob
More information about the Toybox
mailing list