bin/145748: hexdump(1) %s format qualifier broken

Wayne Sierke ws at
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>
To: Garrett Cooper <yanegomi at>
Cc: bug-followup at
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"'
 <  1234>
 <  5678>
 # jot -ns '' 8 1 | hexdump -e '"<%-6.4s>\n"'
 <1234  >
 <5678  >
 > > 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
 making it.
 > 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;
 from hexdump(1):
 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-
 >          versions.
 > 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 mailing list