Date: Tue, 20 Apr 2010 06:40: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: <201004200640.o3K6e332070112@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: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004200640.o3K6e332070112>