in reply to Re^10: Influencing the Gconvert macro
in thread Influencing the Gconvert macro

I suspect that the compiler is (quite reasonably) failing to understand that we check the size of the radix point and adjust float_need accordingly

I had initially assumed that was being checked by the original code but, of course, it was not.
I think you are correct. Having now included such a check, the warning disappears.
That check, as it appears in the 3 patches I posted today to is:
&& sizeof(ebuf) - precis > 10
That was to allow for a leading sign, a leading zero, a decimal point, an exponent (up to 5 bytes), and the terminating NULL byte ... which adds up to 9.
But I think the maximum additional bytes required is only 8. (If that leading zero is present, then there will be no exponent. Right ?)
I decided to allow for an extra exponent byte so that long doubles were accommodated, in case they ever get included in the process. That took it up to 10 bytes and I added one more for safety.
I now believe (even allowing for long doubles) I could have got away with:
&& sizeof(ebuf) - precis > 8
I won't lose too much sleep over that.

As regards float_need, it was always at its initial value of 35 (at least inside the block of code we're discussing).
I could see no sense in looking at it.
I had initially wondered why the processing fell through to a different block of code whenever precis >= 92. It was because 127 - 35 == 92.
We can better determine whether the string will fit into the buffer by looking at the sizeof ebuf and the value of precis .

Thanks for the feedback and help.
I tend to take a very blinkered approach to fixing bugs, concentrating on as narrow a field as is needed to get the job done. So it's certainly advisable that someone undertakes a more open and measured appraisal of what I'm proposing.

I updated today via gmail ... but I don't see the 3 patch files there. (I'll send them to the github thread once I've sent this off and checked that they really are not there.)