bin/145748: hexdump(1) %s format qualifier broken
ws at au.dyndns.ws
Thu Apr 22 02:50:05 UTC 2010
The following reply was made to PR bin/145748; it has been noted by GNATS.
From: Wayne Sierke <ws at au.dyndns.ws>
To: Garrett Cooper <yanegomi at gmail.com>
Cc: bug-followup at freebsd.org
Subject: Re: bin/145748: hexdump(1) %s format qualifier broken
Date: Thu, 22 Apr 2010 12:14:47 +0930
On Tue, 2010-04-20 at 17:49 -0700, Garrett Cooper wrote:
> The issue with %4s failing is still a failure. The non-issue with
> %.4s, %0.4s etc not failing is not a failure; it's just a bit more
> obfuscated logic.
I don't follow. hexdump(1) behaves as described re the "[field]
precision/byte count" value while the "field width" component remains
# jot -ns '' 8 1 | hexdump -e '"<%6.4s>\n"'
# jot -ns '' 8 1 | hexdump -e '"<%-6.4s>\n"'
> > The part of the hexdump(1) manpage quoted previously:
> > o A byte count or field precision is required for each ``s'' con-
> > version character (unlike the fprintf(3) default which prints
> > the entire string if the precision is unspecified).
> That statement is misleading. It should make the above statement with
> field width, not [field] precision.
This seems to be the crux of the claim, but I don't see the basis for
> FWIW, the statement `field
> precision' makes absolutely no sense in the terminology used by
> printf(3), and is most likely a typo.
It's true that the term "field precision" isn't defined but I'd expect
it to generally be taken as referring to "precision". It probably is a
typo in this sense but in this particular application the use of
"precision" rather than "field width" does follow a certain logic:
"precision" from printf(3):
the maximum number of characters to be printed from a string;
The byte count is an optional positive integer. If specified it defines
the number of bytes to be interpreted by each iteration of the format.
> And finally, yes I agree that %s is illegal because you can't qualify
> the number of characters required for each format unit -- something
> that's required for hexdump to function. %4s, etc with precision not
> being specified is legal however.
"%4s" is legal if the "byte count" is specified, eg:
# echo hello, world | hexdump -e '/3 "<%4s>"'
< hel>< lo,>< wo>< rld><
> > And as observed hexdump does accept the required value when passed a
> > "field precision" - the numeric value immediately after the period in
> > "%.4s" (NB not a "field width" - as described in fprintf(3) and slightly
> > more clearly in printf(3)).
> From printf(3):
> o An optional decimal digit string specifying a minimum field width.
> If the converted value has fewer characters than the field width, it
> will be padded with spaces on the left (or right, if the left-adjust-
> ment flag has been given) to fill out the field width.
> o An optional precision, in the form of a period . followed by an
> optional digit string. If the digit string is omitted, the precision
> is taken as zero. This gives the minimum number of digits to appear
> for d, i, o, u, x, and X conversions, the number of digits to appear
> after the decimal-point for a, A, e, E, f, and F conversions, the
> maximum number of significant digits for g and G conversions, or the
> maximum number of characters to be printed from a string for s con-
> Note the word `optional' in the first and second clauses. `.' isn't
> required except to disambiguate precision from field width.
I don't agree with this interpretation. "precision" is optional, but
when present it takes the form of a period optionally followed by a
digit string. That is, when including a precision the period is not
optional but the digit string is. The period is required as a delimiter,
not merely for disambiguation.
More information about the freebsd-bugs