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

[Richard Frith-Macdonald]

> 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.