Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]

[Richard Frith-Macdonald]

> On 21 Jan 2021, at 14:10, Richard Frith-Macdonald 
> <richard@frithmacdonald.me.uk> wrote:
> 
> 
> 
>> On 20 Jan 2021, at 19:48, Fred Kiefer <fredkiefer@gmx.de> wrote:
>> 
>> 
>> 
>>> Am 20.01.2021 um 20:13 schrieb Riccardo Mottola 
>>> <riccardo.mottola@libero.it>:
>>> 
>>> Hi,
>>> 
>>> Fred Kiefer wrote:
>>>>> I will try to bisect - but I'd liek to track this down before a release,
>>>>> especially knowing it is something done these last months.
>>>> If this is really a recent bug, not something that went unnoticed for 
>>>> years as nobody uses SPARC processors any more, than the only possible 
>>>> change would be the float parsing change that Richard just made. No idea 
>>>> why this would fail on something as simple as „1“ or „0“ but this is SPARC 
>>>> specific so you probably should start of by using the test suit of base on 
>>>> that machine.
>>> 
>>> 
>>> Yes... I confirm it is a recent commit and I tracked it down to this commit:
>>> 
>>> ------------------------------------------------------------------------
>>> r23416 | richard.frith.macdonald | 2020-12-30 12:58:19 +0100 (Wed, 30
>>> Dec 2020) | 2 lines
>>> 
>>> Remove internal GSScanInt and GSScanDouble functions after moving
>>> functionality into the -scanDouble: method.  Add private class method to
>>> support scanning a string for a double without having to create a new
>>> scanner each time (use a shared lock-protected, instance with resetting
>>> of the string being scanned).
>>> 
>>> before this, all color look fine.
>>> 
>>> I'm running the tests to see if some specific failed tests can be
>>> identified ... but apparently they run sequentially on only one CPU and
>>> it takes hours....
>>> 
>>> Anyway having an exact commit is also a good start.
>> 
>> 
>> OK, so it is this code in [NSColor colorFromString:] 
>> 
>> 
>> double               r, g, b;
>>     NSScanner *scanner = [[NSScanner alloc] initWithString: str];
>> 
>>     if ([scanner scanDouble: &r] &&
>>        [scanner scanDouble: &g] &&
>>        [scanner scanDouble: &b] &&
>>        [scanner isAtEnd])
>> 
>> In a previous mail you stated that str is something like „1 1 1“ or „0 0 0“. 
>> The next step would be to write a short test program that feeds these 
>> strings to the code above and outputs the values for r, g and b and of 
>> course the result of isAtEnd. That should make it easy to track down the 
>> issue. But you are the only one with a SPARC processor.
> 
> Looks interesting ... do we have the data this is failing on anywhere?
> If I can get a testcase to debug I can see what's going on.


Never mind, I found/fixed it.  Rather than waiting to find out what 'something 
like' meant exactly, I just tried testing with 1 1 1 and with 0 0 0
The problem was the second case ... I had placed a check in the code intended 
to avoid assigning the result of the scan via a nul pointer, but rather than 
checking the pointer i checked the result.
That would mean that, in the case where the scanned value was zero, the result 
was not returned and the memory pointed to was undefined.