svn commit: r364321 - head/sbin/ipfw

Stefan Esser se at freebsd.org
Mon Aug 31 14:44:58 UTC 2020


Am 31.08.20 um 16:09 schrieb Rodney W. Grimes:
>> Hrm, it seems this reply ended up in my spam folder; sorry for not
>> replying until now.
> 
> lol Oh, bad filter :-)
> 
>>>>                        *strchr(timestr, '\n') = '\0';
>>>>                        bprintf(bp, "%s ", timestr);
>>>                                         ^ Isnt this the +1 space?
>>>
>>>>                } else {
>>>> -                     bprintf(bp, "%*s", twidth, " ");
>>>> +                     bprintf(bp, "%*s", twidth + 1, " ");
>>>                                          ^missing from this string?
>>
>> Inserting an extra space in the format string would also work, sure. I
>> considered doing it that way but in the end decided it's not
>> materially more clear one way or another, so used the patch as
>> submitted.
> 
> For me the + 1 leads to a "why is this here", where as the space
> in the format string clearly matches the other condition of the else.

In this case it doesn't seem to make much of a difference, since
the string passed is just a blank character (and it does not make
any difference whether a blank is inserted before or behind it).

But in general, I'd rather see "%*s " as the format (which makes
it clear, that the blank is inserted behind the string argument
referenced by %s, not to the left of it - or " %*s" for the other
placement of the extra blank).

But in this particular case I'd use

	printf(bp, "%*s ", twidth, "");

since there is no need to pass a non-zero length argument for %s and
I'd think that the purpose of the format string is to make the columns
line up and then to provide one additional blank as a separator for
maximum length values.

Adding 1 to the width argument of "%*s" adds blanks to the left of
the string, which is obvious given the semantics of the format string,
but still takes some thinking compared to trivially seeing the place
where the extra blank is put in a format string ...

> Also + 1 causes a run time computation, the extra space does not.

Well, the parsing of the extra blank in the format string can be
assumed to cost more cycles than the increment of a variable plus
the extra loop iteration it causes for the alignment blanks that are
written. But the code length will be shorter with the blank in the
format string and the extra cycles will be irrelevant ...

Regards, STefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20200831/72184120/attachment.sig>


More information about the svn-src-head mailing list