From owner-freebsd-bugs@FreeBSD.ORG Wed Apr 21 23:09:40 2010 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 203FA106566C for ; Wed, 21 Apr 2010 23:09:40 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.211.181]) by mx1.freebsd.org (Postfix) with ESMTP id C7CFB8FC0C for ; Wed, 21 Apr 2010 23:09:39 +0000 (UTC) Received: by ywh11 with SMTP id 11so4523123ywh.7 for ; Wed, 21 Apr 2010 16:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dvXXFMpRcH2USAKDAyd/mBUQFs2xipkl3GB/Fz2AiIA=; b=Zi4JMv3u7FdqcO3AY/RwKy/ms50PzT1MBycyhq0zPRNY7B9x2A/2tmZSN6b0xEija2 MNSgvdt0dDNSvVO1p8EQeEGqyE5sxqzowSGQlagugNCt8O02jJ2d9CGX+OpJSoA1aaSI NgaLUFIm6UXHpiPvnuEAL2XnmW3ptnjSwQF3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Hi6amyfQrUaJNWaSK7bYjA+YurJjh54F92ZuS1O1ZlehE8mtoxGVXpJ8DZjOjbMuzt uLuD8rB8O2AKZG6VC+bAyhTUiaUJT0RsEDUcDjIuvuJRxOcUG4ou7cFXL2vlbQQh8mSJ fV6J54RKsM5LMnsnd2/ILRPEFm6jwkHYBmZiU= MIME-Version: 1.0 Received: by 10.231.191.68 with HTTP; Wed, 21 Apr 2010 16:09:38 -0700 (PDT) In-Reply-To: <20100422023437.J6356@delplex.bde.org> References: <201004210050.o3L0o36p068229@freefall.freebsd.org> <20100422023437.J6356@delplex.bde.org> Date: Wed, 21 Apr 2010 16:09:38 -0700 Received: by 10.150.132.20 with SMTP id f20mr9770179ybd.29.1271891378879; Wed, 21 Apr 2010 16:09:38 -0700 (PDT) Message-ID: From: Garrett Cooper To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-bugs@freebsd.org Subject: Re: bin/145748: hexdump(1) %s format qualifier broken X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 23:09:40 -0000 On Wed, Apr 21, 2010 at 9:50 AM, Bruce Evans wrote: > On Wed, 21 Apr 2010, Garrett Cooper wrote: > >> 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 failur= e >> >> 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 behaviour is as documented. =A0%4s is an invalid format since it has > a field width but no precision. =A0%.4s is a valid format since it has a > precision. > >> > 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. > > Nothing misleading there. =A0The man page should and does match the code, > which takes a field precision. =A0The statement `field precision' exactly > matches printf(3) terminology. printf(3) doesn't explicitly mention `field precision' in the manpage, but yeah... I can kind of see the implicit details in the wording. > I think the field precision, if any, is supposed to be silently ignored, > and the man page doesn't say enough about that, and the code may have > bugs with it, causing the present confusion. =A0I haven't checked exactly > why hexdump uses the precision and not the field width, but this > behaviour makes some sense. =A0Use of the field width would pad the > string, while use of the precision clips it, and hexdump apparently > only supports the latter. bpad() in display.c handles this part. I need to figure out what's going on here to better assess why format the field width couldn't deliver this functionality and why this instead has to be regurgitated via a considerable amount of logic in conv.c, display.c, and parse.c. >> 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 doesn't have any precision. =A0I think %s is supposed to > be legal if there is a precision or a byte count. =A0However, without > these, silently ignoring the field width in %4s reduces it to %s, so > it should cause the same error as %s. > >> > 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 slight= ly >> > more clearly in printf(3)). >> >> From printf(3): >> >> =A0 =A0 o =A0 An optional decimal digit string specifying a minimum fiel= d width. >> =A0 =A0 =A0 =A0 If the converted value has fewer characters than the fie= ld width, >> it >> =A0 =A0 =A0 =A0 will be padded with spaces on the left (or right, if the >> left-adjust- >> =A0 =A0 =A0 =A0 ment flag has been given) to fill out the field width. >> >> =A0 =A0 o =A0 An optional precision, in the form of a period . followed = by an >> =A0 =A0 =A0 =A0 optional digit string. =A0If the digit string is omitted= , the >> precision >> =A0 =A0 =A0 =A0 is taken as zero. =A0This gives the minimum number of di= gits to >> appear >> =A0 =A0 =A0 =A0 for d, i, o, u, x, and X conversions, the number of digi= ts to >> appear >> =A0 =A0 =A0 =A0 after the decimal-point for a, A, e, E, f, and F convers= ions, the >> =A0 =A0 =A0 =A0 maximum number of significant digits for g and G convers= ions, or >> the >> =A0 =A0 =A0 =A0 maximum number of characters to be printed from a string= for s >> con- >> =A0 =A0 =A0 =A0 versions. >> >> Note the word `optional' in the first and second clauses. `.' isn't >> required except to disambiguate precision from field width. > > The "." is part of the syntax for a precision, so it is required to speci= fy > a precision. I've done a lot of mental digesting and additional reading, and yes I now see what you and Wayne were trying to tell me (my misunderstanding of the importance of precision for %s qualifiers as I was mentally inserting precision as it pertains to mathematics, which doesn't make sense when applied to string formats). Please close this bug; it's invalid. Thanks, -Garrett