From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27444 invoked by alias); 17 Aug 2010 11:37:18 -0000 Received: (qmail 27435 invoked by uid 22791); 17 Aug 2010 11:37:17 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.35) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Aug 2010 11:37:11 +0000 Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o7HBb8id015824 for ; Tue, 17 Aug 2010 04:37:08 -0700 Received: from vws3 (vws3.prod.google.com [10.241.21.131]) by hpaq5.eem.corp.google.com with ESMTP id o7HBb6VG028598 for ; Tue, 17 Aug 2010 04:37:07 -0700 Received: by vws3 with SMTP id 3so4452171vws.19 for ; Tue, 17 Aug 2010 04:37:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.59.202 with SMTP id m10mr3874477vch.199.1282045026708; Tue, 17 Aug 2010 04:37:06 -0700 (PDT) Received: by 10.220.83.37 with HTTP; Tue, 17 Aug 2010 04:37:06 -0700 (PDT) In-Reply-To: References: <20100817003114.087EA84B8F@ruffy.mtv.corp.google.com> Date: Tue, 17 Aug 2010 11:37:00 -0000 Message-ID: Subject: Re: [patch] Handle 0 result from sscanf when parsing fp values. From: Doug Evans To: Andreas Schwab Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-08/txt/msg00257.txt.bz2 On Tue, Aug 17, 2010 at 1:18 AM, Andreas Schwab wrote: > dje@google.com (Doug Evans) writes: > >> Index: objc-exp.y >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /cvs/src/src/gdb/objc-exp.y,v >> retrieving revision 1.38 >> diff -u -p -u -p -r1.38 objc-exp.y >> --- objc-exp.y =A0 =A0 =A0 =A05 Mar 2010 20:18:14 -0000 =A0 =A0 =A0 1.38 >> +++ objc-exp.y =A0 =A0 =A0 =A017 Aug 2010 00:17:29 -0000 >> @@ -1016,8 +1016,9 @@ parse_number (p, len, parsed_float, puti >> >> =A0 =A0 =A0 =A0/* It's a float since it contains a point or an exponent.= =A0*/ >> >> - =A0 =A0 =A0sscanf (p, "%" DOUBLEST_SCAN_FORMAT "%c", >> - =A0 =A0 =A0 =A0 =A0 &putithere->typed_val_float.dval, &c); >> + =A0 =A0 =A0if (sscanf (p, "%" DOUBLEST_SCAN_FORMAT "%c", >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 &putithere->typed_val_float.dval, &c) !=3D= 1) > > Shouldn't that be "< 1" since there can be two conversions? > > Andreas. Both p-exp.y and jv-exp.y check sscanf(...) !=3D 1, the %c is there to catch garbage after the number. But it turns out p-exp.y and jv-exp.y are also broken in that they assume the "f" in "1.1f" is accepted by sscanf as part of the number. [They don't do what c-exp.y does which is capture the second conversion as a string and check for valid vs invalid suffixes there.] Blech. I can see that if I'm going to test for sscanf(...) !=3D 1 in objc-exp.y I am going to have to nul-terminate the string first (as the other *-exp.y files do). Otherwise "p 1.1+1" will get flagged as an error. I'll fix that. As it turns out, in objective-c "1.1f" never makes it that far as the caller to objc-exp.y:parse_number will flag 1.1f as an error and never call parse_number. I was prepared to fix "not checking result of sscanf", but I wasn't going to fix all of them in this patch, and the closer I look the more bugs I find. Guess I'll (try to) fix them too.