From nobody@FreeBSD.org  Fri Apr 16 06:38:44 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id C3D9E106566C
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 16 Apr 2010 06:38:44 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id B44B08FC0C
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 16 Apr 2010 06:38:44 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o3G6ciMd013736
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 16 Apr 2010 06:38:44 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o3G6citl013729;
	Fri, 16 Apr 2010 06:38:44 GMT
	(envelope-from nobody)
Message-Id: <201004160638.o3G6citl013729@www.freebsd.org>
Date: Fri, 16 Apr 2010 06:38:44 GMT
From: Garrett Cooper <yaneurabeya@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: hexdump(1) %s format qualifier broken
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         145748
>Category:       bin
>Synopsis:       hexdump(1) %s format qualifier broken
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Apr 16 06:40:00 UTC 2010
>Closed-Date:    Thu Apr 22 00:32:28 UTC 2010
>Last-Modified:  Sun Feb 03 22:28:39 UTC 2013
>Originator:     Garrett Cooper
>Release:        9-CURRENT
>Organization:
Cisco Systems, Inc.
>Environment:
>Description:
According to the manpage...

           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).

.. this should just work. It doesn't however:

$ echo "$(jot -b a 1024)" | hexdump  -e '"%4s\n"'
hexdump: %s: requires a precision or a byte count
>How-To-Repeat:
echo "$(jot -b a 1024)" | hexdump  -e '"%4s\n"'
>Fix:


>Release-Note:
>Audit-Trail:

From: Garrett Cooper <yaneurabeya@gmail.com>
To: bug-followup@FreeBSD.org, gcooper@FreeBSD.org
Cc:  
Subject: Re: bin/145748: hexdump(1) %s format qualifier broken
Date: Fri, 16 Apr 2010 00:25:16 -0700

 This works however:
     echo "$(jot -b a 1024)" | hexdump  -e '/1 "%4s\n"'
 The FSM is skipping over the format qualifier for %s in size()
 according to some basic poking via gdb, because of trailing characters
 after the qualifier:
 
 (gdb) set args -e '"%4s\n"' foo
 (gdb) r
 Starting program: /usr/src/usr.bin/hexdump/hexdump -e '"%4s\n"' foo
 
 Breakpoint 2, size (fs=0x800c07040) at parse.c:174
 174				while (index(spec + 1, *++fmt));
 (gdb) n
 
 Breakpoint 2, size (fs=0x800c07040) at parse.c:174
 174				while (index(spec + 1, *++fmt));
 (gdb) n
 175				if (*fmt == '.' && isdigit(*++fmt)) {
 (gdb) p fmt
 $1 = (unsigned char *) 0x800c09062 "s\n"
 
 So the format strings with the qualifier itself aren't being properly
 divvied up, which is a more difficult state to deal with than I
 originally anticipated I'd be dealing with >:(... This comes back to
 the code mess in add() I have to deal with in several other PRs.
 
 Thanks,
 -Garrett

From: Garrett Cooper <yaneurabeya@gmail.com>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: bin/145748: hexdump(1) %s format qualifier broken
Date: Fri, 16 Apr 2010 11:58:34 -0700

 --Apple-Mail-1--1068145528
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=us-ascii
 
 Begin forwarded message:
 
 > From: Bruce Evans <brde@optusnet.com.au>
 > Date: April 16, 2010 4:25:01 AM PDT
 > To: Garrett Cooper <yaneurabeya@gmail.com>
 > Subject: Re: bin/145748: hexdump(1) %s format qualifier broken
 >=20
 >>> Description:
 >> According to the manpage...
 >>=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
 >> .. this should just work. It doesn't however:
 >>=20
 >> $ echo "$(jot -b a 1024)" | hexdump  -e '"%4s\n"'
 >> hexdump: %s: requires a precision or a byte count
 >>> How-To-Repeat:
 >> echo "$(jot -b a 1024)" | hexdump  -e '"%4s\n"'
 >=20
 > "4" in %4s" is the field width.  "%.4s" has precision 4 and is =
 accepted,
 > but I don't know what most of this is supposed to do so I don't know =
 if
 > this actually works.
 
 For future reference...
 -Garrett=
 
 --Apple-Mail-1--1068145528
 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>Begin forwarded message:</div><br =
 class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
 style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
 margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
 font-size:medium; color:rgba(0, 0, 0, 1);"><b>From: </b></span><span =
 style=3D"font-family:'Helvetica'; font-size:medium;">Bruce Evans &lt;<a =
 href=3D"mailto:brde@optusnet.com.au">brde@optusnet.com.au</a>&gt;<br></spa=
 n></div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
 0px; margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
 font-size:medium; color:rgba(0, 0, 0, 1);"><b>Date: </b></span><span =
 style=3D"font-family:'Helvetica'; font-size:medium;">April 16, 2010 =
 4:25:01 AM PDT<br></span></div><div style=3D"margin-top: 0px; =
 margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span =
 style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, =
 1);"><b>To: </b></span><span style=3D"font-family:'Helvetica'; =
 font-size:medium;">Garrett Cooper &lt;<a =
 href=3D"mailto:gcooper@FreeBSD.org">gcooper@FreeBSD.org</a>&gt;<br></span>=
 </div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
 0px; margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
 font-size:medium; color:rgba(0, 0, 0, 1);"><b>Subject: </b></span><span =
 style=3D"font-family:'Helvetica'; font-size:medium;"><b>Re: bin/145748: =
 hexdump(1) %s format qualifier =
 broken</b><br></span></div><br><div><blockquote type=3D"cite"><blockquote =
 type=3D"cite">Description:<br></blockquote></blockquote><blockquote =
 type=3D"cite">According to the manpage...<br></blockquote><blockquote =
 type=3D"cite"><br></blockquote><blockquote type=3D"cite"> =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o &nbsp;&nbsp;A =
 byte count or field precision is required for each ``s'' =
 con-<br></blockquote><blockquote type=3D"cite"> =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
 bsp;version character (unlike the fprintf(3) default which =
 prints<br></blockquote><blockquote type=3D"cite"> =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
 bsp;the entire string if the precision is =
 unspecified).<br></blockquote><blockquote =
 type=3D"cite"><br></blockquote><blockquote type=3D"cite">.. this should =
 just work. It doesn't however:<br></blockquote><blockquote =
 type=3D"cite"><br></blockquote><blockquote type=3D"cite">$ echo "$(jot =
 -b a 1024)" | hexdump &nbsp;-e '"%4s\n"'<br></blockquote><blockquote =
 type=3D"cite">hexdump: %s: requires a precision or a byte =
 count<br></blockquote><blockquote type=3D"cite"><blockquote =
 type=3D"cite">How-To-Repeat:<br></blockquote></blockquote><blockquote =
 type=3D"cite">echo "$(jot -b a 1024)" | hexdump &nbsp;-e =
 '"%4s\n"'<br></blockquote><br>"4" in %4s" is the field width. =
 &nbsp;"%.4s" has precision 4 and is accepted,<br>but I don't know what =
 most of this is supposed to do so I don't know if<br>this actually =
 works.</div></blockquote></div><br><div>For future =
 reference...</div><div>-Garrett</div></body></html>=
 
 --Apple-Mail-1--1068145528--

From: Wayne Sierke <ws@au.dyndns.ws>
To: Garrett Cooper <yaneurabeya@gmail.com>
Cc: bug-followup@freebsd.org
Subject: Re: bin/145748: hexdump(1) %s format qualifier broken
Date: Tue, 20 Apr 2010 12:33:14 +0930

 >  > "4" in %4s" is the field width.  "%.4s" has precision 4 and is =
 >  accepted,
 >  > but I don't know what most of this is supposed to do so I don't know =
 >  if
 >  > this actually works.
 
 As noted by Bruce, the provided test-case was setting field width
 instead of field precision. This seems to be a case of "works as
 advertised".
 
 # jot -b a 1024 | hexdump -e '"%.4s\n"'
 a
 a
 
 *
 # jot -b a 1024 | hexdump -e ' /4 "%s\n"'
 a
 a
 
 *
 # 
 
 I did stumble upon the following, however, which looks like a bug (if I
 haven't missed something):
 
 # jot -w "%07d" 32 0 | tr '\012' '\040' | hexdump -e '"%.32s\n"'
 0000000 0000001 0000002 0000003 
 0000004 0000005 0000006 0000007 
 0000008 0000009 0000010 0000011 
 0000012 0000013 0000014 0000015 
 0000016 0000017 0000018 0000019 
 0000020 0000021 0000022 0000023 
 0000024 0000025 0000026 0000027 
 0000028 0000029 0000030 0000031 
 # jot -w "%07d" 32 0 | tr '\012' '\040' | hexdump -e '/32 "%s\n"'
 0000000 0000001 0000002 0000003 
 0000004 0000005 0000006 0000007 
 0000008 0000009 0000010 0000011 0000004 0000005 0000006 0000007 
 0000012 0000013 0000014 0000015 
 0000016 0000017 0000018 0000019 0000012 0000013 0000014 0000015 
 0000020 0000021 0000022 0000023 
 0000024 0000025 0000026 0000027 0000020 0000021 0000022 0000023 
 0000028 0000029 0000030 0000031 
 # 
 
 Seems to be reproducible for "byte count" = 2^n (n=1,2,3,...).
 
 Should probably go in a new PR (although I haven't checked for an
 existing one).
 
 

From: Garrett Cooper <yaneurabeya@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: Mon, 19 Apr 2010 23:31:41 -0700

 On Mon, Apr 19, 2010 at 8:03 PM, Wayne Sierke <ws@au.dyndns.ws> wrote:
 >> =A0> "4" in %4s" is the field width. =A0"%.4s" has precision 4 and is =
 =3D
 >> =A0accepted,
 >> =A0> but I don't know what most of this is supposed to do so I don't kno=
 w =3D
 >> =A0if
 >> =A0> this actually works.
 >
 > As noted by Bruce, the provided test-case was setting field width
 > instead of field precision. This seems to be a case of "works as
 > advertised".
 
 Except from a programming perspective it really doesn't make sense to
 support a field width from a strict standpoint, whereas the relaxed
 version, like so works and is standard in multiple programming
 languages out there:
 
 "%4s"
 
 The fact that "%4s" fails and isn't noted in the addendum is a failure
 according to the specifications of hexdump as per the manpage; "%.4s"
 passing is a reasonable workaround for broken "%[:digit:]s"
 functionality.
 
 I have a patch for this, but it's a part of a much bigger change that
 I'm working on for hexdump, and I'd rather this be documented so we
 can move on to the point where all of the items need to be committed
 all at once and all of these PRs can be fixed.
 
 > # jot -b a 1024 | hexdump -e '"%.4s\n"'
 > a
 > a
 >
 > *
 > # jot -b a 1024 | hexdump -e ' /4 "%s\n"'
 > a
 > a
 >
 > *
 > #
 >
 > I did stumble upon the following, however, which looks like a bug (if I
 > haven't missed something):
 >
 > # jot -w "%07d" 32 0 | tr '\012' '\040' | hexdump -e '"%.32s\n"'
 > 0000000 0000001 0000002 0000003
 > 0000004 0000005 0000006 0000007
 > 0000008 0000009 0000010 0000011
 > 0000012 0000013 0000014 0000015
 > 0000016 0000017 0000018 0000019
 > 0000020 0000021 0000022 0000023
 > 0000024 0000025 0000026 0000027
 > 0000028 0000029 0000030 0000031
 > # jot -w "%07d" 32 0 | tr '\012' '\040' | hexdump -e '/32 "%s\n"'
 > 0000000 0000001 0000002 0000003
 > 0000004 0000005 0000006 0000007
 > 0000008 0000009 0000010 0000011 0000004 0000005 0000006 0000007
 > 0000012 0000013 0000014 0000015
 > 0000016 0000017 0000018 0000019 0000012 0000013 0000014 0000015
 > 0000020 0000021 0000022 0000023
 > 0000024 0000025 0000026 0000027 0000020 0000021 0000022 0000023
 > 0000028 0000029 0000030 0000031
 > #
 >
 > Seems to be reproducible for "byte count" =3D 2^n (n=3D1,2,3,...).
 
 I think this is a bug in display.c in terms of how it's consuming
 bytes. I'll analyze it tonight and figure out whether or not the issue
 is valid (looks like it but I want to be sure), and figure out where
 the problem needs to be fixed (it's present in my modified version and
 the original).
 
 > Should probably go in a new PR (although I haven't checked for an
 > existing one).
 
 Cheers :),
 -Garrett

From: Wayne Sierke <ws@au.dyndns.ws>
To: Garrett Cooper <yaneurabeya@gmail.com>
Cc: bug-followup@freebsd.org
Subject: Re: bin/145748: hexdump(1) %s format qualifier broken
Date: Wed, 21 Apr 2010 00:03:30 +0930

 > The fact that "%4s" fails and isn't noted in the addendum is a failure
 > according to the specifications of hexdump as per the manpage; "%.4s"
 > passing is a reasonable workaround for broken "%[:digit:]s"
 > functionality.
 
 I should have made my earlier reply more explicit. It doesn't seem to be
 a failure.
 
 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).
 
 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: Garrett Cooper <yaneurabeya@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: Tue, 20 Apr 2010 17:49:43 -0700

 On Tue, Apr 20, 2010 at 7:33 AM, Wayne Sierke <ws@au.dyndns.ws> wrote:
 >> The fact that "%4s" fails and isn't noted in the addendum is a failure
 >> according to the specifications of hexdump as per the manpage; "%.4s"
 >> passing is a reasonable workaround for broken "%[:digit:]s"
 >> functionality.
 >
 > I should have made my earlier reply more explicit. It doesn't seem to be
 > a failure.
 
 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.
 
 > 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. FWIW, the statement `field
 precision' makes absolutely no sense in the terminology used by
 printf(3), and is most likely a typo.
 
 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.
 
 > 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.
 
 Thanks,
 -Garrett
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Thu Apr 22 00:32:20 UTC 2010 
State-Changed-Why:  
Closed at submitter's request. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145748 

From: Wayne Sierke <ws@au.dyndns.ws>
To: Garrett Cooper <yaneurabeya@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.
 
 

From: Garrett Cooper <yaneurabeya@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 '"&lt;%6.4s&gt;\n"'<br>&lt; &nbsp;1234&gt;<br>&lt; =
 &nbsp;5678&gt;<br># jot -ns '' 8 1 | hexdump -e =
 '"&lt;%-6.4s&gt;\n"'<br>&lt;1234 &nbsp;&gt;<br>&lt;5678 &nbsp;&gt;<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. &nbsp;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 =
 "&lt;%4s&gt;"'<br>&lt; hel&gt;&lt; lo,&gt;&lt; &nbsp;wo&gt;&lt; =
 rld&gt;&lt; &nbsp;&nbsp;<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"> =
 &nbsp;&nbsp;&nbsp;&nbsp;o &nbsp;&nbsp;An optional decimal digit string =
 specifying a minimum field width.<br></blockquote><blockquote =
 type=3D"cite"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;If the =
 converted value has fewer characters than the field width, =
 it<br></blockquote><blockquote type=3D"cite"> =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;will be padded with =
 spaces on the left (or right, if the =
 left-adjust-<br></blockquote><blockquote type=3D"cite"> =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ment flag has been =
 given) to fill out the field width.<br></blockquote><blockquote =
 type=3D"cite"><br></blockquote><blockquote type=3D"cite"> =
 &nbsp;&nbsp;&nbsp;&nbsp;o &nbsp;&nbsp;An optional precision, in the form =
 of a period . followed by an<br></blockquote><blockquote type=3D"cite"> =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;optional digit string. =
 &nbsp;If the digit string is omitted, the =
 precision<br></blockquote><blockquote type=3D"cite"> =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;is taken as zero. =
 &nbsp;This gives the minimum number of digits to =
 appear<br></blockquote><blockquote type=3D"cite"> =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for d, i, o, u, x, and X =
 conversions, the number of digits to appear<br></blockquote><blockquote =
 type=3D"cite"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;after the =
 decimal-point for a, A, e, E, f, and F conversions, =
 the<br></blockquote><blockquote type=3D"cite"> =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;maximum number of =
 significant digits for g and G conversions, or =
 the<br></blockquote><blockquote type=3D"cite"> =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;maximum number of =
 characters to be printed from a string for s =
 con-<br></blockquote><blockquote type=3D"cite"> =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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--
>Unformatted:
