NetBSD Problem Report #39135

From cheusov@tut.by  Sat Jul 12 00:33:13 2008
Return-Path: <cheusov@tut.by>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 7243263BCE5
	for <gnats-bugs@gnats.netbsd.org>; Sat, 12 Jul 2008 00:33:13 +0000 (UTC)
Message-Id: <s93abgof26e.fsf@chen.chizhovka.net>
Date: Sat, 12 Jul 2008 02:09:45 +0300
From: cheusov@tut.by
Reply-To:
To: gnats-bugs@gnats.NetBSD.org
Subject: /usr/bin/awk: printf supports extra- (and broken) formatting rules
X-Send-Pr-Version: 3.95

>Number:         39135
>Category:       bin
>Synopsis:       /usr/bin/awk: formatting issues in printf
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul 12 00:35:01 +0000 2008
>Last-Modified:  Sun Jul 13 17:05:02 +0000 2008
>Originator:     cheusov@tut.by
>Release:        NetBSD 4.0_STABLE
>Organization:
>Environment:
System: NetBSD chen.chizhovka.net 4.0_STABLE NetBSD 4.0_STABLE (GENERIC) #0: Sun Jul 6 22:33:53 EEST 2008 cheusov@chen.chizhovka.net:/srv/obj/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:
  0 ~>awk 'BEGIN {printf "%llu\n", 123}' 
  4398046511227
  0 ~>

Rules are there 

  http://www.opengroup.org/onlinepubs/009695399/utilities/awk.html

  "The printf statement shall produce output based on a notation
  similar to the File Format Notation used to describe file formats in
  this volume of IEEE Std 1003.1-2001 (see the Base Definitions volume
  of IEEE Std 1003.1-2001, Chapter 5, File Format Notation).
  ...
  ...
  "

This PR is again based on OpenBSD gnats

   http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=5523

>Fix:

Unknown
>Audit-Trail:
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: bin/39135: /usr/bin/awk: printf supports extra- (and broken) formatting rules
Date: Sat, 12 Jul 2008 11:51:59 -0400

 On Jul 12, 12:35am, cheusov@tut.by (cheusov@tut.by) wrote:
 -- Subject: bin/39135: /usr/bin/awk: printf supports extra- (and broken) form

 | Rules are there 
 | 
 |   http://www.opengroup.org/onlinepubs/009695399/utilities/awk.html
 | 
 |   "The printf statement shall produce output based on a notation
 |   similar to the File Format Notation used to describe file formats in
 |   this volume of IEEE Std 1003.1-2001 (see the Base Definitions volume
 |   of IEEE Std 1003.1-2001, Chapter 5, File Format Notation).
 |   ...
 |   ...
 |   "
 | 
 | This PR is again based on OpenBSD gnats
 | 
 |    http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=5523

 But if you follow the link:

 http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap05.html

 You'll see that there is no mention of the 'l' modifier, and OpenBSD
 similarly closed the PR.

 [11:49am] 8395>awk 'BEGIN { printf("%llx\n", 0xffffffffffLL); }'
 40000000000
 [11:49am] 8396>gawk 'BEGIN { printf("%llx\n", 0xffffffffffLL); }'
 %llx

 The question is should we completely remove support for %l, do a half-assed
 job like we do now, by not handling long long, or fix %lld?

 christos

From: "Greg A. Woods; Planix, Inc." <woods@planix.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/39135: /usr/bin/awk: printf supports extra- (and broken) formatting rules
Date: Sat, 12 Jul 2008 11:58:12 -0400

 On 11-Jul-08, at 8:35 PM, cheusov@tut.by wrote:

 > awk 'BEGIN {printf "%llu\n", 123}'


 Hah!  Interesting side effect of directly using printf(3)!  ;-)

 The simplest fix might be that AWK should disallow format specifiers  
 which do not use parameters of the same width which it(AWK) passes to  
 printf().

 -- 
 					Greg A. Woods; Planix, Inc.
 					<woods@planix.ca>

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/39135: /usr/bin/awk: printf supports extra- (and broken) formatting rules
Date: Sat, 12 Jul 2008 18:24:41 +0100

 On Sat, Jul 12, 2008 at 04:00:06PM +0000, Greg A. Woods; Planix, Inc. wrote:
 > The following reply was made to PR bin/39135; it has been noted by GNATS.
 > 
 > From: "Greg A. Woods; Planix, Inc." <woods@planix.ca>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: bin/39135: /usr/bin/awk: printf supports extra- (and broken) formatting rules
 > Date: Sat, 12 Jul 2008 11:58:12 -0400
 > 
 >  On 11-Jul-08, at 8:35 PM, cheusov@tut.by wrote:
 >  
 >  > awk 'BEGIN {printf "%llu\n", 123}'
 >  
 >  
 >  Hah!  Interesting side effect of directly using printf(3)!  ;-)

 So using %n will have interesting effects ...

 	David

 -- 
 David Laight: david@l8s.co.uk

From: Aleksey Cheusov <cheusov@tut.by>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/39135: /usr/bin/awk: printf supports extra- (and broken) formatting rules
Date: Sat, 12 Jul 2008 21:51:21 +0300

 >  |    http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=5523
 >  
 >  But if you follow the link:
 >  
 >  http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap05.html
 >  
 >  You'll see that there is no mention of the 'l' modifier, and OpenBSD
 >  similarly closed the PR.
 Yes, "length modifiers" are not allowed for awk's printf operator
 and it's safer to disallow them explicitly.

 Quick check: between % sign and [diouxXfeEgGcs] character (on the right side)
 only the following chars are allowed: [-+0-9 #].

 >  The question is should we completely remove support for %l, do a half-assed
 >  job like we do now, by not handling long long, or fix %lld?
 %l should be disabled because there is no such "conversion
 specifiers". %lld - too because "length modifiers" are
 not allowed for awk's printf (see above).

 -- 
 Best regards, Aleksey Cheusov.

From: "Greg A. Woods; Planix, Inc." <woods@planix.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/39135: /usr/bin/awk: printf supports extra- (and broken) formatting rules
Date: Sun, 13 Jul 2008 13:03:17 -0400

 On 12-Jul-08, at 1:30 PM, David Laight wrote:
 >
 > On Sat, Jul 12, 2008 at 04:00:06PM +0000, Greg A. Woods; Planix,  
 > Inc. wrote:
 >> The following reply was made to PR bin/39135; it has been noted by  
 >> GNATS.
 >>
 >> From: "Greg A. Woods; Planix, Inc." <woods@planix.ca>
 >> To: gnats-bugs@NetBSD.org
 >> Cc:
 >> Subject: Re: bin/39135: /usr/bin/awk: printf supports extra- (and  
 >> broken) formatting rules
 >> Date: Sat, 12 Jul 2008 11:58:12 -0400
 >>
 >> On 11-Jul-08, at 8:35 PM, cheusov@tut.by wrote:
 >>
 >>> awk 'BEGIN {printf "%llu\n", 123}'
 >>
 >>
 >> Hah!  Interesting side effect of directly using printf(3)!  ;-)
 >
 > So using %n will have interesting effects ...


 Not so much.  I goofed in remembering how much of the formatting was  
 handed off to libc.  It's actually sprintf(3) that's used to format  
 numbers, and only after all the '%' syntax in the format string has  
 (supposedly) been decoded for the most part.  "%n" isn't directly  
 supported.  See run.c:format() and the following example.

 	$ awk 'BEGIN {printf "%n\n", 123}'
 	awk: weird printf conversion %n
 	 source line number 1
 	%n123

 I'm still not sure what exactly is wrong with AWK's use of sprintf()  
 -- on first glance I would have thought that the "long long" flag  
 should already be ignored, though on closer examination it seems any  
 number of length flags will be skipped over _and_ preserved and passed  
 to sprintf():

 	$ awk 'BEGIN {printf "%llllld\n", 123}'
 	578115701986820219
 	$ awk 'BEGIN {printf "%#0lllllx\n", 123}'
 	0x805e12b0000007b

 Perhaps the code from printf(1) [which seems to get this stuff right]  
 could be enhanced to match AWK's requirements and then be used to  
 replace the existing format() function.

 On the other hand fixing the isalfpha() && != 'l' && != 'h' && != 'L'  
 test to be much more stringent  (in the manner of how printf(1) does  
 it) would perhaps be the least intrusive fix.

 -- 
 					Greg A. Woods; Planix, Inc.
 					<woods@planix.ca>

Home	PR Database Search