Date: Thu, 22 Apr 2010 08:10:03 GMT From: Garrett Cooper <yanegomi@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/145748: hexdump(1) %s format qualifier broken Message-ID: <201004220810.o3M8A3ew053172@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: Garrett Cooper <yanegomi@gmail.com> To: Wayne Sierke <ws@au.dyndns.ws> 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 <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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004220810.o3M8A3ew053172>