Re: [patch] Handle 0 result from sscanf when parsing fp values.

[Doug Evans <dje@google.com>]

On Tue, Aug 17, 2010 at 1:18 AM, Andreas Schwab <schwab@redhat.com> wrote:
> dje@google.com (Doug Evans) writes:
>
>> Index: objc-exp.y
>> ===================================================================
>> 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        5 Mar 2010 20:18:14 -0000       1.38
>> +++ objc-exp.y        17 Aug 2010 00:17:29 -0000
>> @@ -1016,8 +1016,9 @@ parse_number (p, len, parsed_float, puti
>>
>>        /* It's a float since it contains a point or an exponent.  */
>>
>> -      sscanf (p, "%" DOUBLEST_SCAN_FORMAT "%c",
>> -           &putithere->typed_val_float.dval, &c);
>> +      if (sscanf (p, "%" DOUBLEST_SCAN_FORMAT "%c",
>> +               &putithere->typed_val_float.dval, &c) != 1)
>
> Shouldn't that be "< 1" since there can be two conversions?
>
> Andreas.

Both p-exp.y and jv-exp.y check sscanf(...) != 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(...) != 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.