From owner-freebsd-bugs@FreeBSD.ORG Thu Apr 22 08:10:03 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C11F1065674 for ; Thu, 22 Apr 2010 08:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3CF5B8FC1D for ; Thu, 22 Apr 2010 08:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3M8A3XU053173 for ; Thu, 22 Apr 2010 08:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3M8A3ew053172; Thu, 22 Apr 2010 08:10:03 GMT (envelope-from gnats) Date: Thu, 22 Apr 2010 08:10:03 GMT Message-Id: <201004220810.o3M8A3ew053172@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Garrett Cooper Cc: Subject: Re: bin/145748: hexdump(1) %s format qualifier broken X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Garrett Cooper List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 08:10:03 -0000 The following reply was made to PR bin/145748; it has been noted by GNATS. From: Garrett Cooper To: Wayne Sierke Cc: bug-followup@freebsd.org Subject: Re: bin/145748: hexdump(1) %s format qualifier broken Date: Thu, 22 Apr 2010 01:06:19 -0700 --Apple-Mail-1--588879786 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 21, 2010, at 7:44 PM, Wayne Sierke wrote: > 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. >=20 > I don't follow. hexdump(1) behaves as described re the "[field] > precision/byte count" value while the "field width" component remains > functional: >=20 > # jot -ns '' 8 1 | hexdump -e '"<%6.4s>\n"' > < 1234> > < 5678> > # jot -ns '' 8 1 | hexdump -e '"<%-6.4s>\n"' > <1234 > > <5678 > > #=20 >=20 >>> The part of the hexdump(1) manpage quoted previously: >>>=20 >>> 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). >>=20 >> That statement is misleading. It should make the above statement with >> field width, not [field] precision. >=20 > This seems to be the crux of the claim, but I don't see the basis for > making it. >=20 >> FWIW, the statement `field >> precision' makes absolutely no sense in the terminology used by >> printf(3), and is most likely a typo. >=20 > 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: >=20 > "precision" from printf(3): > the maximum number of characters to be printed from a string; >=20 > 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. >=20 >> 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. >=20 > "%4s" is legal if the "byte count" is specified, eg: >=20 > # echo hello, world | hexdump -e '/3 "<%4s>"' > < hel>< lo,>< wo>< rld>< =20 >> # >=20 >>> 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)). >>=20 >> =46rom printf(3): >>=20 >> 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. >>=20 >> 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. >>=20 >> Note the word `optional' in the first and second clauses. `.' isn't >> required except to disambiguate precision from field width. >=20 > 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. I understand what you and Bruce were trying to say this morning; = it was all my misunderstanding because I didn't properly understand the = concept of precision and how it pertained to %s qualifiers. I'm filing a bug for the other item you saw earlier. I've = determine what the issue was and have solved it in my private workspace. Thanks, -Garrett= --Apple-Mail-1--588879786 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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)).

=46rom = 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.

I = understand what you and Bruce were trying to say this morning; it was = all my misunderstanding because I didn't properly understand the concept = of precision and how it pertained to %s qualifiers.
I'm = filing a bug for the other item you saw earlier. I've determine what the = issue was and have solved it in my private = workspace.
Thanks,
-Garrett
= --Apple-Mail-1--588879786--