in reply to Re^6: Avoiding perl's Atof when assigning floating point values
in thread Avoiding perl's Atof when assigning floating point values

It then dawned upon me that if it's ok for quadmath builds to skip those tests, then it's ok for my patched approach to also skip them

However, quadmath's inability to pass those tests didn't change any pre-existing behaviour, whereas my patches have changed behaviour - and that might not be greeted so warmly.
I probably ought at least find out exactly what that change of behaviour is - though it's as clear as mud to me at the moment.
It would be great if anyone has some clear code that demonstrates what has actually changed.
In the meantime, it's back to perusing the perllocale docs and lib/locale.t. (Is there some other documentation that might be helpful to me ?)

Cheers,
Rob
  • Comment on Re^7: Avoiding perl's Atof when assigning floating point values

Replies are listed 'Best First'.
Re^8: Avoiding perl's Atof when assigning floating point values
by syphilis (Archbishop) on Jul 31, 2018 at 14:36 UTC
    I probably ought at least find out exactly what that change of behaviour is

    Here's the script that demonstrates that change of behaviour:
    use warnings; use locale; $m = "3.14e+9" + 0; $n = "3,14e+9" + 0; print "\$m is $m\n"; print "\$n is $n\n";
    On current bleadperl (and recent "double" and "long double" perls) it outputs:
    $m is 3140000000 $n is 3140000000
    But when I patch bleadperl to assign with Perl_strtod (or run that script on a quadmath build of perl) it outputs:
    $m is 3140000000 $n is 3
    AFAICT, it pertains solely to the numification of strings. When values are assigned as barewords, there's no difference between the behaviour of the various builds.
    And I think it comes into play only if the locale radix character is a comma.
    My next step is to find out whether this needs to be fixed before my proposed patches can be applied.

    Cheers,
    Rob