bin/145748: hexdump(1) %s format qualifier broken

[Garrett Cooper]

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: Mon, 19 Apr 2010 23:31:41 -0700

 On Mon, Apr 19, 2010 at 8:03 PM, Wayne Sierke <ws at 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