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

I've been a little despondent about the lib/locale.t failures ever since I became aware of them a few days ago.
But, tonight, I think I've found the correct way to deal with them.
Under make test there seems to be only the one failing test in lib/locale.t, but there's an additional 4 tests that fail if one runs ./perl -I./lib -T locale.t
There's no problem with those 5 tests on quadmath builds, irrespective of locale ... why is that ? ... it's because they're skipped on quadmath builds.

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. (Like the quadmath builds, my approach also assigns NVs using the underlying C compiler via Perl_strtod.)
Having just modified lib/locale.t to skip those tests whenever Perl_strtod is defined, I find that all tests now pass !!

I just need to provide patches against current blead, and hope that I can get Karl and/or Jim to create another smoke-me branch for more testing.
If I can just get those patches into blead .....

Cheers,
Rob

Replies are listed 'Best First'.
Re^7: Avoiding perl's Atof when assigning floating point values
by syphilis (Archbishop) on Jul 30, 2018 at 11:27 UTC
    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
[reply]
      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";

      [download]
      On current bleadperl (and recent "double" and "long double" perls) it outputs: 
      $m is 3140000000
$n is 3140000000

      [download]
      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

      [download]
      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
[reply]
[d/l]
[select]

In Section Meditations