Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Re^10: Influencing the Gconvert macro

by hv (Prior)
on Oct 06, 2020 at 04:09 UTC ( [id://11122559]=note: print w/replies, xml ) Need Help??

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

- && sizeof(ebuf) - float_need > precis + && sizeof(ebuf) - float_need > precis + 7

Thanks for digging. :) 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 - that it assumes worst case we will not enter that branch (of which it in any case cannot reasonably understand the intent), and so its analysis acts as if we're always treating the radix point as width 1.

It would probably be reasonable to make the above change (but probably folding it into float_need instead:

- + 1 /* default radix point '.' */ + + 8 /* worst case radix point */
) and remove the later "float_need += (SvCUR(PL_numeric_radix_sv) - 1)". Though it's sad that this isn't enough to remove the need for the whole WITH_LC_NUMERIC_SET_TO_NEEDED_IN malarkey.

I'll respond to the github issue separately, it'll take me some time to go through the options you describe.


Replies are listed 'Best First'.
Re^11: Influencing the Gconvert macro
by syphilis (Archbishop) on Oct 06, 2020 at 09:59 UTC
    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.)


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11122559]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (2)
As of 2024-04-17 05:10 GMT
Find Nodes?
    Voting Booth?

    No recent polls found