Re: Bug in [NSScanner scanDouble:]

[Richard Frith-Macdonald]

> On 29 Dec 2020, at 10:10, Richard Frith-Macdonald 
> <richard@frithmacdonald.me.uk> wrote:
> 
> 
> 
>> On 29 Dec 2020, at 09:32, Fred Kiefer <fredkiefer@gmx.de> wrote:
>> 
>> Looks like the code of GSScanDouble and [NSScanner scanDouble:] differ a 
>> lot. Both are in the file NSScanner.m and it looks like the function has 
>> been corrected over the years to handle different cases a lot better. The 
>> NSScanner code is just a straight forward number scanning as you would 
>> expect.
>> 
>> The easiest solution would be to reuse GSScanDouble by scanning in a buffer 
>> all the characters for the double value and calling the function on that 
>> value (handling _decimal by replacing it with a dot). But somehow this feels 
>> like the wrong way around.
> 
> I think that probably *is* the way to go.  That way the NSScanner method 
> would be responsible for converting to a unicode character buffer from 
> whatever string representation it is handling (and finding the end of the 
> potential double), while the function would be responsible for ensuring that 
> the characters in the buffer actually represents a double.  We know the 
> maximum number of characters in a double, so we can use an on-stack buffer 
> and the whole thing would be reasonably efficient.

But having done that (having the method put data into a buffer and passing that 
buffer to the function), to the point where it builds/works,  I now think it's 
probably the wrong way to go.  The reason being that a string may contain a 
huge number of leading zeros (so requiring a very large buffer), and it would 
therefore make sense to have code which would read input character-by-character 
and discard leading zeros (and/or excess digits beyond the precision limits of 
a double) rather than buffering them all.