Re: What magic be this?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 17 Mar 2017 16:44:08 +0100
    From:        Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost>
    Message-ID:  <m2k27nq56f.fsf%thuvia.hamartun.priv.no@localhost>


  | Looks good at first glance, right?  Now take a look at the printf
  | statements in /usr/src/usr.bin/vmstat/vmstat.c that did that:
  | 
  | [...]
  | (void)printf("%-34s %16s %8s\n", "interrupt", "total", "rate");
  | [...]
  | (void)printf("%-34s %16llu %8llu\n", intrname,
  | [...]

Are you sure they did that?   Look a little earlier ...

        if (nintr != 0 && inamlen != 0) {
		/* those printfs occur here */
	}
	doevcnt(verbose, EVCNT_TYPE_INTR);

Then in doevcnt() we see (heading) ...

                (void)printf(type == EVCNT_TYPE_ANY ?
                    "%-*s  %*s %*s %s\n" :
                    "%-*s  %*s %*s\n",
                    (int)evlen_max, "interrupt",
                    (int)total_max, "total",
                    (int)rate_max, "rate",
                    "type");

"type" is the 2nd arg to doevcnt(), and as we saw it is EVCNT_TYPE_INTR
it (most probably) is not EVCNT_TYPE_ANY, so we know which format string
is being used (the second one).

Then (in a loop)

                        (void)printf(type == EVCNT_TYPE_ANY ?
                            "%s %s%*s  %*"PRIu64" %*"PRIu64" %s\n" :
                            "%s %s%*s  %*"PRIu64" %*"PRIu64"\n",
                            evs->ev_strings,
                            evs->ev_strings + evs->ev_grouplen + 1,
                            (int)evlen_max - (evs->ev_grouplen + 1
                            + evs->ev_namelen), "",
                            (int)total_max, evs->ev_count,
                            (int)rate_max, evs->ev_count / uptime,
                            (evs->ev_type < __arraycount(evtypes) ?
                            evtypes[evs->ev_type] : "?"));

the data, with, in both cases, the field widths calculated.

  | So what the heck is going on here?

The code is doing what it is written to do.    That is almost always
what happens (regardless of whether it is what we want it to do).
If you can't see how the code is causing the effect that is observed,
it just means that you're not looking hard enough (or that you have
pre-conceived notions that you are refusing to accept may be incorrect.)

If there is some code that is expecting field width of 34, 16, and 8,
for some bizarre reason, then that's way too fragile, and should be fixed.

The number at the end of the line is the rate, that's preceded by spaces,
and just before it, the absolute value of the counter, then earlier more
spaces, and the rest of the line (at the beginning) is the name (which may
contain embedded spaces.)   Parse it like that and there should be no problems.

kre