Date: Thu, 22 Apr 2010 02:50:04 GMT From: Wayne Sierke <ws@au.dyndns.ws> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/145748: hexdump(1) %s format qualifier broken Message-ID: <201004220250.o3M2o4QX047440@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/145748; it has been noted by GNATS. From: Wayne Sierke <ws@au.dyndns.ws> To: Garrett Cooper <yanegomi@gmail.com> Cc: bug-followup@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 functional: # 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004220250.o3M2o4QX047440>