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