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
