http://www.perlmonks.org?node_id=1217849


in reply to Avoiding perl's Atof when assigning floating point values

I still fail to see "why P5P could not simply adopt this . . . and be done."
  • Comment on Re: Avoiding perl's Atof when assigning floating point values

Replies are listed 'Best First'.
Re^2: Avoiding perl's Atof when assigning floating point values
by syphilis (Archbishop) on Jul 04, 2018 at 13:01 UTC
    I still fail to see "why P5P could not simply adopt this . . . and be done."

    Yeah ... maybe I was concentrating more on the reasons that (I believe) they would not, rather than reasons that they could not.
    And the bug with windows strtold() turned out to be far less significant than I thought it would be.
    Its looking like __mingw_strtold should be an alias for strtold (just as __mingw_strtod is an alias for strtod), but for some reason (probably oversight), that's not happening.
    In any case, the patch that handles this bug does so as efficiently as would fixing the bug in the mingw-w64 port of gcc.

    I just can't see p5p adopting this patch simply on the basis of the testing that I've done - though I'll probably raise it with them again once I've managed to properly prepare myself for the eventuality of being ignored once more. (Not a particularly pleasurable experience.)

    Cheers,
    Rob
      I just can't see p5p adopting this patch simply on the basis of the testing that I've done

      The good news is that there has been some more testing done.
      Karl Williamson and Jim Keenan created smoke-me branches to specifically test my changes (at http://perl.develop-help.com/?b=smoke-me%2Fkhw-sisyphus and http://perl.develop-help.com/?b=smoke-me%2Fjkeenan%2Fsisyphus%2F41202-2nd-text-float respectively). Many thanks to Karl and Jim for doing that.

      The bad news is that the results aren't great. The one smoker (Carlos Guevara's) that has tested those branches has frequently encountered lib/locale.t test failures.
      It has also encountered other problems, such as ticket #133356 and ticket #133377, but they are separate issues not related to my changes - and I've no need to concern myself with them for now.

      OTOH, the lib/locale.t failures seems to have arisen from the changes I've made, and that's the issue I need to address.
      Unfortunately, I can't reproduce those failures locally - and I'm hoping that someone here might be able to help out.

      The source for Karl Williamson's branch is here. I would love to enter into a dialog with anyone who can download that file, unpack it, and build from it (on a Unix-type system) a perl that fails any lib/locale.t tests. (I have questions regarding the %Config and locale settings for such a perl).
      Having unpacked the source, cd to the top level folder and run:
      sh Configure -des -Dusedevel -Duse64bitall && make && make test
      Examining the individual reports for Karl's branch, I can see that the lib/locale.t failures that I'm interested in are occurring on all of Carlos's FreeBSD and NetBSD systems (but not his OpenBSD system), on his Solaris system, on his slackware system, on his Fedora systems, and on his Ubuntu-14.04 (but not 16.04 or 18.04) system.

      I have 2 things to say to anyone who can help me out with this:
      1) thank you ever so much;
      2) get a life ;-)

      Cheers,
      Rob

        Hi! Running the code you offered (in a container, though), I've got:

        lib/locale ..................................................... FAILE +D at test 427 lib/locale_threads ............................................. skipp +ed
        I'm running Debian 9.4; my locale is ru_RU.UTF-8. The failures might be related to the fact the my locale (like some European ones) uses a comma (,) as decimal separator1, unlike a dot (.) as expected by "C" locale: https://paste.debian.net/1035555/ (a PM post doesn't seem to be enough for this log).

        Here is my %Config, as obtained by cd t; ./perl -I../lib -MData::Dumper -MConfig -e'print Dumper \%Config':

        Is there anything else I could send you?

        1Yes, it has bitten me in the past when I wrote a library to talk to a device using standard C string formatting functions, then something else in the process called setlocale(LC_ALL, "") and everything got broken.