> On 21 Jan 2021, at 14:10, Richard Frith-Macdonald
> <rich...@frithmacdonald.me.uk> wrote:
>
>
>
>> On 20 Jan 2021, at 19:48, Fred Kiefer <fredkie...@gmx.de> wrote:
>>
>>
>>
>>> Am 20.01.2021 um 20:13 schrieb Riccardo Mottola
>>> <riccardo.mott...@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.