From owner-freebsd-bugs@FreeBSD.ORG Wed Apr 21 00:50:03 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A04C4106564A for ; Wed, 21 Apr 2010 00:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8F9248FC0C for ; Wed, 21 Apr 2010 00:50:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3L0o3OO068230 for ; Wed, 21 Apr 2010 00:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3L0o36p068229; Wed, 21 Apr 2010 00:50:03 GMT (envelope-from gnats) Date: Wed, 21 Apr 2010 00:50:03 GMT Message-Id: <201004210050.o3L0o36p068229@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Garrett Cooper Cc: Subject: Re: bin/145748: hexdump(1) %s format qualifier broken X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Garrett Cooper List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 00:50:03 -0000 The following reply was made to PR bin/145748; it has been noted by GNATS. From: Garrett Cooper To: Wayne Sierke 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 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