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

[Riccardo Mottola]

Hi!

Richard Frith-Macdonald wrote:
> 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.

oh.. I was still testing while you fixed it! You are one of the best ones!

Tests on Intel:
2021-01-21 15:17:27.353 ScannerTest[3312:3312] parsed: 1.000000,
1.000000, 1.000000 - isAtEnd? 1
2021-01-21 15:17:27.354 ScannerTest[3312:3312] parsed: 0.000000,
0.000000, 0.000000 - isAtEnd? 1

Tests on Sparc:
2021-01-21 16:19:47.859 ScannerTest[20968:3930190728] parsed: 1.000000,
1.000000, 1.000000 - isAtEnd? 1
2021-01-21 16:19:47.913 ScannerTest[20968:3930190728] parsed: 0.000000,
0.000000, 0.000000 - isAtEnd? 1

once again.. the code was general, but SPARC was more sensitive....

I was proposing to add it to the test suite, but I saw you did with a
later commit. Does it make sense to have both 1 & 0 as tests?


I also confirm that now interface colors come up correctly on both
SPARC32-bit and SPARC64bit.
With Fred's fixes in GUI... SPARC64 is working fine again, I can launch
several complex applications like GWorkspace and PRICE without spotting
gross errors.


Riccardo