[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;


  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();


  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

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...


More information about the Toybox mailing list