Closed p5pRT closed 5 years ago
ce6f496d720f6206455628425320badd95b07372 changed float/double formatting from strtoflt128 to Perl_strtod\, which had a nasty side effect when running under non-english locales (or I suspect with locales that use comma for decimal point) together with GTK or any other library that calls setlocale() itself.
The test for this is rather elaborate\, so I'm attaching a localebug module that tests for it when run 'make test'. One needs the following (for Ubuntu\, for example):
* apt-get install libgtk2.0-dev (gtk development files) * cpan ExtUtils::PkgConfig * locale-gen de_DE.UTF-8 && update-locale (tests need de_DE.UTF-8)
When running with a faulty configuration\, the core issue is basically this:
my $s = sprintf "%s"\, 4.9999; die "bug:$s" if $s !~ /^4[\,.]9999$/;
which prints just "4".
The module attached can also be found at http://karasik.eu.org/misc/localebug-1.00.tar.gz
Very similar issue (fixed in 5.20.1) https://rt.perl.org/Public/Bug/Display.html?id=122105
On Wed\, 20 Mar 2019 18:03:23 GMT\, int32 wrote:
This is a bug report for perl from dmitry@karasik.eu.org\, generated with the help of perlbug 1.41 running under perl 5.29.2.
----------------------------------------------------------------- [Please describe your issue here]
ce6f496d720f6206455628425320badd95b07372 changed float/double formatting from strtoflt128 to Perl_strtod\, which had a nasty side effect when running under non-english locales (or I suspect with locales that use comma for decimal point) together with GTK or any other library that calls setlocale() itself.
The test for this is rather elaborate\, so I'm attaching a localebug module that tests for it when run 'make test'. One needs the following (for Ubuntu\, for example):
* apt-get install libgtk2.0-dev (gtk development files) * cpan ExtUtils::PkgConfig * locale-gen de_DE.UTF-8 && update-locale (tests need de_DE.UTF-8)
When running with a faulty configuration\, the core issue is basically this:
my $s = sprintf "%s"\, 4.9999; die "bug:$s" if $s !~ /^4[\,.]9999$/;
which prints just "4".
The module attached can also be found at http://karasik.eu.org/misc/localebug-1.00.tar.gz
bcc-ing relevant parties.
-- James E Keenan (jkeenan@cpan.org)
The RT System itself - Status changed from 'new' to 'open'
On Wed\, 20 Mar 2019 18:03:23 GMT\, int32 wrote:
This is a bug report for perl from dmitry@karasik.eu.org\, generated with the help of perlbug 1.41 running under perl 5.29.2.
----------------------------------------------------------------- [Please describe your issue here]
ce6f496d720f6206455628425320badd95b07372 changed float/double formatting from strtoflt128 to Perl_strtod\, which had a nasty side effect when running under non-english locales (or I suspect with locales that use comma for decimal point) together with GTK or any other library that calls setlocale() itself.
The test for this is rather elaborate\, so I'm attaching a localebug module that tests for it when run 'make test'. One needs the following (for Ubuntu\, for example):
* apt-get install libgtk2.0-dev (gtk development files) * cpan ExtUtils::PkgConfig * locale-gen de_DE.UTF-8 && update-locale (tests need de_DE.UTF-8)
When running with a faulty configuration\, the core issue is basically this:
my $s = sprintf "%s"\, 4.9999; die "bug:$s" if $s !~ /^4[\,.]9999$/;
which prints just "4".
The module attached can also be found at http://karasik.eu.org/misc/localebug-1.00.tar.gz
In order to run the tests in your tarball\, I would have to become the root user (or sudo) and change the default locale. I am reluctant to do that and\, in any case\, we have to be able to run the Perl 5 core test suite as non-root users.
Could your tests be modified so that an ordinary user could run them?
Thank you very much.
-- James E Keenan (jkeenan@cpan.org)
In order to run the tests in your tarball\, I would have to become the root user (or sudo) and change the default locale. I am reluctant to do that and\, in any case\, we have to be able to run the Perl 5 core test suite as non-root users.
That's not entirely correct. You may need to become root to install the prerequisites (gtk headers and ExtUtils::PkgConfig you can install locally though)\, but locales are OS-specific by design\, and if yours has a way to use one without root\, that's great. However the tests themselves don't need root.
Could your tests be modified so that an ordinary user could run them?
If p5 core has already tests for another locale\, simulating file access required to load proper de_DE.UTF-8 or similar\, please point me to them and I can try to hack on. Otherwise I know about locale-dependend tests as much as the next guy\, unfortunately\, but again\, tests are completely fine with an ordinary user\, provided proper prerequisites are installed.
/dk
Thank you very much.
-- James E Keenan (jkeenan@cpan.org)
-- Sincerely\, Dmitry Karasik
On Thu\, 21 Mar 2019 14:28:37 GMT\, int32 wrote:
In order to run the tests in your tarball\, I would have to become the root user (or sudo) and change the default locale. I am reluctant to do that and\, in any case\, we have to be able to run the Perl 5 core test suite as non-root users.
That's not entirely correct. You may need to become root to install the prerequisites (gtk headers and ExtUtils::PkgConfig you can install locally though)\, but locales are OS-specific by design\, and if yours has a way to use one without root\, that's great. However the tests themselves don't need root.
Could your tests be modified so that an ordinary user could run them?
If p5 core has already tests for another locale\, simulating file access required to load proper de_DE.UTF-8 or similar\, please point me to them and I can try to hack on. Otherwise I know about locale-dependend tests as much as the next guy\, unfortunately\, but again\, tests are completely fine with an ordinary user\, provided proper prerequisites are installed.
/dk
Thank you very much.
-- James E Keenan (jkeenan@cpan.org)
Is this expected output from running the tests in your tarball (where de_DE.utf8 is available but not default)?
##### $ locale | head -1 LANG=en_US.UTF-8
$ locale -a | grep '^de_DE.utf8' de_DE.utf8
$ prove -I. -vb t/*.t t/C-explicit.t ... 1..1 ok 1 ok t/C-implicit.t ... 1..1 ok 1 ok t/DE-explicit.t .. 1..1 ok 1 ok t/DE-implicit.t .. 1..1 ok 1 ok t/DE.t ........... 1..1 ok 1 - Setting locale failed: please install de_DE.UTF-8 ok t/none.t ......... 1..1 ok 1 ok All tests successful. Files=6\, Tests=6\, 1 wallclock secs ( 0.04 usr 0.00 sys + 0.12 cusr 0.03 csys = 0.19 CPU) Result: PASS #####
Thank you very much.
-- James E Keenan (jkeenan@cpan.org)
Is this expected output from running the tests in your tarball (where de_DE.utf8 is available but not default)?
Hi James\,
Yes indeed it is. That's how it looks when everyting is fine and there's no bug. It's a bit misleading with
ok 1 - Setting locale failed: please install de_DE.UTF-8
but when run with 'make test' it is suppressed\, and is only shown on failure
/dk
##### $ locale | head -1 LANG=en_US.UTF-8
$ locale -a | grep '^de_DE.utf8' de_DE.utf8
$ prove -I. -vb t/*.t t/C-explicit.t ... 1..1 ok 1 ok t/C-implicit.t ... 1..1 ok 1 ok t/DE-explicit.t .. 1..1 ok 1 ok t/DE-implicit.t .. 1..1 ok 1 ok t/DE.t ........... 1..1 ok 1 - Setting locale failed: please install de_DE.UTF-8 ok t/none.t ......... 1..1 ok 1 ok All tests successful. Files=6\, Tests=6\, 1 wallclock secs ( 0.04 usr 0.00 sys + 0.12 cusr 0.03 csys = 0.19 CPU) Result: PASS #####
Hi James\,
-- Sincerely\, Dmitry Karasik
Complete locale numbnut here\, who is puzzled at how to account for the behaviour being demonstrated. (Feel free to educate me ... or to ignore me.)
In perllocale docs I see:
\
Also Perl gives access to various C library functions through
the POSIX module. Some of those functions are always affected by
the current locale. For example\, "POSIX::strftime()" uses
"LC_TIME"; "POSIX::strtod()" uses "LC_NUMERIC";
"POSIX::strcoll()" and "POSIX::strxfrm()" use "LC_COLLATE". All
such functions will behave according to the current underlying
locale\, even if that locale isn't exposed to Perl space.
\
With the perl that Dmitry has used\, Perl_strtod is simply the C library function strtod(). Is the section I've just quoted stating that strtod (and hence Perl_strtod) "will behave according to the current underlying locale\, even if that locale isn't exposed to Perl space" ?
If so\, is that what's happening here ? Is Gtk2 altering the "current underlying locale" in such a way that C's strtod() is affected\, while perl's atof functionality (which Perl_strtod replaces) would be unaffected ?
FYI: For a perl whose nvtype is "double" one can revert to using perl's less accurate atof functionality by configuring the build with '-Ud_strtod'. For -Duselongdouble builds\, to avoid Perl_strtod (ie C library's strtold) specify '-Ud_strtod -Ud_strtold'. For -Dusequadmath builds one is currently stuck with Perl_strtod (ie C library's strtoflt128).
Cheers\, Rob
On Thu\, Mar 21\, 2019 at 08:16:52PM -0700\, sisyphus@cpan.org via RT wrote:
Complete locale numbnut here\, who is puzzled at how to account for the behaviour being demonstrated. (Feel free to educate me ... or to ignore me.)
Here's a good explanation on the similar issue:
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=122105
(it's buried somewhere in the discussion).
Basically Perl has the idea that it is master of setlocale()\, while GTK disagrees\, both for good reasons. So IIUC Perl syncs the locale state one in a while\, while I personally think authors integrating those libs should do that\, explicitly -- but that's too late now\, as it will break lots of modules.
Is Gtk2 altering the "current underlying locale" in such a way that C's strtod() is affected\, while perl's atof functionality (which Perl_strtod replaces) would be unaffected ?
It seems that way to me.
-- Sincerely\, Dmitry Karasik
On 3/22/19 4:31 AM\, Dmitry Karasik wrote:
On Thu\, Mar 21\, 2019 at 08:16:52PM -0700\, sisyphus@cpan.org via RT wrote:
Complete locale numbnut here\, who is puzzled at how to account for the behaviour being demonstrated. (Feel free to educate me ... or to ignore me.)
Here's a good explanation on the similar issue:
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=122105
(it's buried somewhere in the discussion).
You can start way down\, at https://rt-archive.perl.org/perl5/Ticket/Display.html?id=121930#txn-1298035
Basically Perl has the idea that it is master of setlocale()\, while GTK disagrees\, both for good reasons. So IIUC Perl syncs the locale state one in a while\, while I personally think authors integrating those libs should do that\, explicitly -- but that's too late now\, as it will break lots of modules.
Actually\, you have it somewhat wrong. See below
Is Gtk2 altering the "current underlying locale" in such a way that C's strtod() is affected\, while perl's atof functionality (which Perl_strtod replaces) would be unaffected ?
It seems that way to me.
See https://perldoc.pl/5.29.9/perlapi#Locale-related-functions-and-macros
Perl keeps the LC_NUMERIC locale generally set to the C locale. This is for the benefit of all the XS code that has been written over the years that assumes the decimal point character is a dot. It's too late to change that code.
But there are times when the radix character needs to be output in the locale-appropriate form\, which in many European locales is a comma. There are now various macros\, listed at the link above\, that are used in the perl core to switch to that locale for the purposes of output\, and then immediately switch back. Calling the underlying C function directly bypasses this logic.
I haven't looked at this ticket carefully enough to be sure\, but wrapping the strtod() calls with these might be the answer?
And then there's GTK which sets the locale itself. That can't be helped\, but XS code that calls it can call sync_locale() before returning to perl. There is no periodic syncing.
Things are further complicated by the fact that POSIX systems have a completely independent way of setting locales. Perl converted to use that for threaded builds in 5.28\, as that system is thread-safe\, while the older setlocale() isn't. I was expecting to get some bug reports about this versus GTK\, but haven't. (Maybe no one is using threaded perls with that\, or maybe GTK got smarter and uses the new set under threads). XS code that wants to change the locale itself should instead use Perl_setlocale() starting in 5.28\, as that knows which set to use.
The bottom line is you can't use a LC_NUMERIC locale-sensitive library function directly from perl. It has to be wrapped with the macro calls. I chose not to wrap the functions in the POSIX module\, like POSIX::strtod() because it hadn't been and I didn't want to break things that actually relied on that. That actually means I had to "unwrap" them\, to switch LC_NUMERIC to the real underlying one before calling the function\, and then switching back.
On Fri\, Mar 22\, 2019 at 09:53:40AM -0600\, Karl Williamson wrote:
And then there's GTK which sets the locale itself. That can't be helped\, but XS code that calls it can call sync_locale() before returning to perl. There is no periodic syncing.
Thanks for the explanation\, that makes sense. This will help me fixing my affected code; I wish I knew about Perl_sync_locale() before.
-- Sincerely\, Dmitry Karasik
On Fri\, 22 Mar 2019 15:11:00 -0700\, int32 wrote:
On Fri\, Mar 22\, 2019 at 09:53:40AM -0600\, Karl Williamson wrote:
And then there's GTK which sets the locale itself. That can't be helped\, but XS code that calls it can call sync_locale() before returning to perl. There is no periodic syncing.
Thanks for the explanation\, that makes sense. This will help me fixing my affected code; I wish I knew about Perl_sync_locale() before.
Where would you have read that putting a link to perlapi for this would have shown you it existed? -- Karl Williamson
On Sat\, Mar 23\, 2019 at 11:26:22AM -0700\, Karl Williamson via RT wrote:
On Fri\, 22 Mar 2019 15:11:00 -0700\, int32 wrote:
On Fri\, Mar 22\, 2019 at 09:53:40AM -0600\, Karl Williamson wrote:
And then there's GTK which sets the locale itself. That can't be helped\, but XS code that calls it can call sync_locale() before returning to perl. There is no periodic syncing.
Thanks for the explanation\, that makes sense. This will help me fixing my affected code; I wish I knew about Perl_sync_locale() before.
Where would you have read that putting a link to perlapi for this would have shown you it existed?
"Read" assumes active monitoring of such news\, which I almost never do. Reaching to authors that have GTK-related modules would be nice though; there aren't that many of those. I've got a heads up last time about a similar issue from Slaven Rezic who runs cpantests massively\, and I'm grateful for that.
-- Sincerely\, Dmitry Karasik
On 3/25/19 9:30 AM\, Dmitry Karasik wrote:
On Sat\, Mar 23\, 2019 at 11:26:22AM -0700\, Karl Williamson via RT wrote:
On Fri\, 22 Mar 2019 15:11:00 -0700\, int32 wrote:
On Fri\, Mar 22\, 2019 at 09:53:40AM -0600\, Karl Williamson wrote:
And then there's GTK which sets the locale itself. That can't be helped\, but XS code that calls it can call sync_locale() before returning to perl. There is no periodic syncing.
Thanks for the explanation\, that makes sense. This will help me fixing my affected code; I wish I knew about Perl_sync_locale() before.
Where would you have read that putting a link to perlapi for this would have shown you it existed?
"Read" assumes active monitoring of such news\, which I almost never do. Reaching to authors that have GTK-related modules would be nice though; there aren't that many of those. I've got a heads up last time about a similar issue from Slaven Rezic who runs cpantests massively\, and I'm grateful for that.
I meant\, where in the perl docs would you have gone when you noticed the problem. I'm presuming you looked at them\, but didn't find a reference to this function.
Thanks for the explanation\, that makes sense. This will help me fixing my affected code; I wish I knew about Perl_sync_locale() before.
Where would you have read that putting a link to perlapi for this would have shown you it existed?
"Read" assumes active monitoring of such news\, which I almost never do. Reaching to authors that have GTK-related modules would be nice though; there aren't that many of those. I've got a heads up last time about a similar issue from Slaven Rezic who runs cpantests massively\, and I'm grateful for that. I meant\, where in the perl docs would you have gone when you noticed the problem. I'm presuming you looked at them\, but didn't find a reference to this function.
I didn't go to the docs at all. My timeline was something like this:
- Slaven sent a pull request for my module (Prima) to workaround perl bug in 5.20.1 that failed tests - Between 5.20.1 and 5.28 everything was fine - I started to see failures again after 5.29.2\, that I could reproduce and fix by the same workaround as did for 5.20.1 - I bisected and submitted a patch
Even if I did go for the docs\, I wouldn't have a slightest idea where to look for\, because I wasn't familiar that locale syncing is a problem at all. I though think that this is okay\, Perl is full of such hidden pieces one simply has to know. By the same token I look into C code generated by XS (because I also generate C/Perl glue code but without XS) to see what have changed\, and these changes I don't expect to see in the docs either.
For the constructive note\, it might be a (probably even good) idea to issue a warning if perl detects discrepancy between real C locale and expected locale\, pointing that authors should read about sync_locale().
-- Sincerely\, Dmitry Karasik
On 3/20/19 12:03 PM\, Dmitry Karasik (via RT) wrote:
# New Ticket Created by Dmitry Karasik # Please include the string: [perl #133945] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133945 >
This is a bug report for perl from dmitry@karasik.eu.org\, generated with the help of perlbug 1.41 running under perl 5.29.2.
----------------------------------------------------------------- [Please describe your issue here]
ce6f496d720f6206455628425320badd95b07372 changed float/double formatting from strtoflt128 to Perl_strtod\, which had a nasty side effect when running under non-english locales (or I suspect with locales that use comma for decimal point) together with GTK or any other library that calls setlocale() itself.
The test for this is rather elaborate\, so I'm attaching a localebug module that tests for it when run 'make test'. One needs the following (for Ubuntu\, for example):
* apt-get install libgtk2.0-dev (gtk development files) * cpan ExtUtils::PkgConfig * locale-gen de_DE.UTF-8 && update-locale (tests need de_DE.UTF-8)
When running with a faulty configuration\, the core issue is basically this:
my $s = sprintf "%s"\, 4\.9999; die "bug​:$s" if $s \!~ /^4\[\,\.\]9999$/;
which prints just "4".
The module attached can also be found at http://karasik.eu.org/misc/localebug-1.00.tar.gz
[Please do not change anything below this line]
I tried your (thoughtfully included) test bed\, making sure that perl.h was changed to call straight strtod()\, and couldn't get it to fail.
But I created a branch where I wrap Perl_strtod() with calls to use the proper radix character. Please try it out and report back.
It's at https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/khw-strtod
I tried your (thoughtfully included) test bed\, making sure that perl.h was changed to call straight strtod()\, and couldn't get it to fail.
But I created a branch where I wrap Perl_strtod() with calls to use the proper radix character. Please try it out and report back.
It's at https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/khw-strtod
Hi Karl\,
That branch seems to be passing the tests okay
-- Sincerely\, Dmitry Karasik
This should be fixed by commit 4ac6fab20b8950ee14756c6f2438809c572082cd Author: Karl Williamson \khw@​cpan\.org Date: Mon Apr 15 11:10:31 2019 -0600
PATCH: [perl #133945] Perl_strtod failures
This commit wraps Perl_strtod() in macros that cause the proper radix
character to be used.
-- Karl Williamson
@khwilliamson - Status changed from 'open' to 'pending release'
Unfortunately this latest commit (4ac6fab20b8950ee14756c6f2438809c572082cd) gets us back to assigning values incorrectly. (Perl's test suite will not presently detect this.) I guess we've now somehow gone back to using perl's atof() function for assignment of floating point values. At least\, it seems that the values being assigned are now the same as the values that perl's atof() assigns.
A quick check that will catch the problem is to run something like: $ perl -MPOSIX -le 'print "wtf" if POSIX::strtod("8.87359152e-6") != 8.87359152e-6;'
When nvtype is 'double\, the value of 8.87359152e-6 is assigned incorrectly by perl's atof on a number of platforms\, including Windows and Linux - so it's a good value to test.
Perhaps we should even add that test to the POSIX test suite ? We'd need to test a different value for -Duselongdouble builds - I'll write a patch for posix.t and submit it later today in a separate bug report. That way\, if Perl_strtod() is defined but perl's atof() is being used\, we'd find out about it when perl's test suite is run.
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 7:53 AM Karl Williamson via RT \< perlbug-followup@perl.org> wrote:
This should be fixed by commit 4ac6fab20b8950ee14756c6f2438809c572082cd Author: Karl Williamson \khw@​cpan\.org Date: Mon Apr 15 11:10:31 2019 -0600
PATCH​: \[perl \#133945\] Perl\_strtod failures This commit wraps Perl\_strtod\(\) in macros that cause the proper radix character to be used\.
-- Karl Williamson
--- via perlbug: queue: perl5 status: open https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133945
On 4/15/19 8:39 PM\, sisyphus wrote:
Unfortunately this latest commit (4ac6fab20b8950ee14756c6f2438809c572082cd) gets us back to assigning values incorrectly. (Perl's test suite will not presently detect this.) I guess we've now somehow gone back to using perl's atof() function for assignment of floating point values. At least\, it seems that the values being assigned are now the same as the values that perl's atof() assigns.
I re-inspected the patch and don't see anyway that it could have made this switcheroo.
A quick check that will catch the problem is to run something like: $ perl -MPOSIX -le 'print "wtf" if POSIX::strtod("8.87359152e-6") != 8.87359152e-6;'
When nvtype is 'double\, the value of 8.87359152e-6 is assigned incorrectly by perl's atof on a number of platforms\, including Windows and Linux - so it's a good value to test.
Perhaps we should even add that test to the POSIX test suite ? We'd need to test a different value for -Duselongdouble builds - I'll write a patch for posix.t and submit it later today in a separate bug report.
That sounds good.
That way\, if Perl_strtod() is defined but perl's atof() is being used\, we'd find out about it when perl's test suite is run.
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 7:53 AM Karl Williamson via RT \<perlbug-followup@perl.org \mailto​:perlbug\-followup@​perl\.org> wrote:
This should be fixed by commit 4ac6fab20b8950ee14756c6f2438809c572082cd Author​: Karl Williamson \<khw@​cpan\.org \<mailto​:khw@​cpan\.org>> Date​: Mon Apr 15 11​:10​:31 2019 \-0600 PATCH​: \[perl \#133945\] Perl\_strtod failures This commit wraps Perl\_strtod\(\) in macros that cause the proper radix character to be used\. \-\- Karl Williamson \-\-\- via perlbug​: queue​: perl5 status​: open https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133945
Something in the last couple of days has definitely caused a reversion to use of perl's atof().
This Inline::C script: ######################## use warnings; use Inline C => \<\<'EOC'; void foo() { #ifdef Perl_strtod printf("Perl_strtod defined\n"); #else printf("Perl_strtod NOT defined\n"); #endif } EOC foo(); ########################
reports (on all of my Windows and Linux builds) that current blead has Perl_strtod NOT defined. If Perl_strtod is not defined then I don't think that Perl_strtod can be assigning the values - it must surely be perl's atof() that's doing the assigning.
My -Dusequadmath builds are also afflicted with the issue (as they now also do not define Perl_strtod). That's not a reversion - this is the first time ever that quadmath builds have used perl's atof()\, and the result is not pretty.
Anyway - perhaps it's not your commit that's the culprit. It has to be something fairly recent because I built blead a couple of days ago and it was fine. (My builds do check that strtod/strtold/strtoflt128 are being used.) I haven't even yet glanced at the current perl source. I've instead been trying to gauge the scope of the breakage - which is something that took me far longer than it ought.
I'll prepare and post that patch to posix.t tonight\, and try to get my head around the perl source tomorrow.
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 1:50 PM Karl Williamson \public@​khwilliamson\.com wrote:
On 4/15/19 8:39 PM\, sisyphus wrote:
Unfortunately this latest commit (4ac6fab20b8950ee14756c6f2438809c572082cd) gets us back to assigning values incorrectly. (Perl's test suite will not presently detect this.) I guess we've now somehow gone back to using perl's atof() function for assignment of floating point values. At least\, it seems that the values being assigned are now the same as the values that perl's atof() assigns.
I re-inspected the patch and don't see anyway that it could have made this switcheroo.
A quick check that will catch the problem is to run something like: $ perl -MPOSIX -le 'print "wtf" if POSIX::strtod("8.87359152e-6") != 8.87359152e-6;'
When nvtype is 'double\, the value of 8.87359152e-6 is assigned incorrectly by perl's atof on a number of platforms\, including Windows and Linux - so it's a good value to test.
Perhaps we should even add that test to the POSIX test suite ? We'd need to test a different value for -Duselongdouble builds - I'll write a patch for posix.t and submit it later today in a separate bug report.
That sounds good.
That way\, if Perl_strtod() is defined but perl's atof() is being used\, we'd find out about it when perl's test suite is run.
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 7:53 AM Karl Williamson via RT \<perlbug-followup@perl.org \mailto​:perlbug\-followup@​perl\.org> wrote:
This should be fixed by commit 4ac6fab20b8950ee14756c6f2438809c572082cd Author​: Karl Williamson \<khw@​cpan\.org \<mailto​:khw@​cpan\.org>> Date​: Mon Apr 15 11​:10​:31 2019 \-0600 PATCH​: \[perl \#133945\] Perl\_strtod failures This commit wraps Perl\_strtod\(\) in macros that cause the proper radix character to be used\. \-\- Karl Williamson \-\-\- via perlbug​: queue​: perl5 status​: open https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133945
On 4/16/19 4:53 AM\, sisyphus wrote:
Something in the last couple of days has definitely caused a reversion to use of perl's atof().
This Inline::C script: ######################## use warnings; use Inline C => \<\<'EOC'; void foo() { #ifdef Perl_strtod printf("Perl_strtod defined\n"); #else printf("Perl_strtod NOT defined\n"); #endif } EOC foo(); ########################
I can confirm this result on Linux.
Is there any way your C program could be rewritten such that we get a Perl exit 0 on defined and a Perl exit 1 on NOT defined? If we had that\, then we could plug it into Porting/bisect.pl.
reports (on all of my Windows and Linux builds) that current blead has Perl_strtod NOT defined. If Perl_strtod is not defined then I don't think that Perl_strtod can be assigning the values - it must surely be perl's atof() that's doing the assigning.
My -Dusequadmath builds are also afflicted with the issue (as they now also do not define Perl_strtod). That's not a reversion - this is the first time ever that quadmath builds have used perl's atof()\, and the result is not pretty.
Anyway - perhaps it's not your commit that's the culprit. It has to be something fairly recent because I built blead a couple of days ago and it was fine. (My builds do check that strtod/strtold/strtoflt128 are being used.) I haven't even yet glanced at the current perl source. I've instead been trying to gauge the scope of the breakage - which is something that took me far longer than it ought.
I'll prepare and post that patch to posix.t tonight\, and try to get my head around the perl source tomorrow.
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 1:50 PM Karl Williamson \<public@khwilliamson.com \mailto​:public@​khwilliamson\.com> wrote:
On 4/15/19 8​:39 PM\, sisyphus wrote​: > Unfortunately this latest commit > \(4ac6fab20b8950ee14756c6f2438809c572082cd\) gets us back to assigning > values incorrectly\. \(Perl's test suite will not presently detect this\.\) > I guess we've now somehow gone back to using perl's atof\(\) function for > assignment of floating point values\. > At least\, it seems that the values being assigned are now the same as > the values that perl's atof\(\) assigns\. I re\-inspected the patch and don't see anyway that it could have made this switcheroo\. > > A quick check that will catch the problem is to run something like​: > $ perl \-MPOSIX \-le 'print "wtf" if POSIX​::strtod\("8\.87359152e\-6"\) \!= > 8\.87359152e\-6;' > > When nvtype is 'double\, the value of 8\.87359152e\-6 is assigned > incorrectly by perl's atof on a number of platforms\, including Windows > and Linux \- so it's a good value to test\. > > Perhaps we should even add that test to the POSIX test suite ? > We'd need to test a different value for \-Duselongdouble builds \- I'll > write a patch for posix\.t and submit it later today in a separate bug > report\. That sounds good\. > That way\, if Perl\_strtod\(\) is defined but perl's atof\(\) is being used\, > we'd find out about it when perl's test suite is run\. > > Cheers\, > Rob > > On Tue\, Apr 16\, 2019 at 7​:53 AM Karl Williamson via RT > \<perlbug\-followup@​perl\.org \<mailto​:perlbug\-followup@​perl\.org> \<mailto​:perlbug\-followup@​perl\.org \<mailto​:perlbug\-followup@​perl\.org>>> wrote​: > > This should be fixed by > commit 4ac6fab20b8950ee14756c6f2438809c572082cd > Author​: Karl Williamson \<khw@​cpan\.org \<mailto​:khw@​cpan\.org> \<mailto​:khw@​cpan\.org \<mailto​:khw@​cpan\.org>>> > Date​: Mon Apr 15 11​:10​:31 2019 \-0600 > > PATCH​: \[perl \#133945\] Perl\_strtod failures > > This commit wraps Perl\_strtod\(\) in macros that cause the > proper radix > character to be used\. > > \-\- > Karl Williamson > > \-\-\- > via perlbug​: queue​: perl5 status​: open > https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133945 >
James\, Does the following behave as desired ?
##################### use warnings; use Inline C => \<\<'EOC'; int foo() { #ifdef Perl_strtod return 0; #else return 1; #endif } EOC exit(foo()); ####################
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 9:59 PM James E Keenan \jkeenan@​pobox\.com wrote:
On 4/16/19 4:53 AM\, sisyphus wrote:
Something in the last couple of days has definitely caused a reversion to use of perl's atof().
This Inline::C script: ######################## use warnings; use Inline C => \<\<'EOC'; void foo() { #ifdef Perl_strtod printf("Perl_strtod defined\n"); #else printf("Perl_strtod NOT defined\n"); #endif } EOC foo(); ########################
I can confirm this result on Linux.
Is there any way your C program could be rewritten such that we get a Perl exit 0 on defined and a Perl exit 1 on NOT defined? If we had that\, then we could plug it into Porting/bisect.pl.
reports (on all of my Windows and Linux builds) that current blead has Perl_strtod NOT defined. If Perl_strtod is not defined then I don't think that Perl_strtod can be assigning the values - it must surely be perl's atof() that's doing the assigning.
My -Dusequadmath builds are also afflicted with the issue (as they now also do not define Perl_strtod). That's not a reversion - this is the first time ever that quadmath builds have used perl's atof()\, and the result is not pretty.
Anyway - perhaps it's not your commit that's the culprit. It has to be something fairly recent because I built blead a couple of days ago and it was fine. (My builds do check that strtod/strtold/strtoflt128 are being used.) I haven't even yet glanced at the current perl source. I've instead been trying to gauge the scope of the breakage - which is something that took me far longer than it ought.
I'll prepare and post that patch to posix.t tonight\, and try to get my head around the perl source tomorrow.
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 1:50 PM Karl Williamson \<public@khwilliamson.com \mailto​:public@​khwilliamson\.com> wrote:
On 4/15/19 8​:39 PM\, sisyphus wrote​: > Unfortunately this latest commit > \(4ac6fab20b8950ee14756c6f2438809c572082cd\) gets us back to
assigning
values incorrectly. (Perl's test suite will not presently detect this.) I guess we've now somehow gone back to using perl's atof() function for assignment of floating point values. At least\, it seems that the values being assigned are now the same as the values that perl's atof() assigns.
I re\-inspected the patch and don't see anyway that it could have made this switcheroo\. > > A quick check that will catch the problem is to run something
like:
$ perl -MPOSIX -le 'print "wtf" if POSIX::strtod("8.87359152e-6") != 8.87359152e-6;'
When nvtype is 'double\, the value of 8.87359152e-6 is assigned incorrectly by perl's atof on a number of platforms\, including Windows and Linux - so it's a good value to test.
Perhaps we should even add that test to the POSIX test suite ? We'd need to test a different value for -Duselongdouble builds - I'll write a patch for posix.t and submit it later today in a separate bug report.
That sounds good\. > That way\, if Perl\_strtod\(\) is defined but perl's atof\(\) is being used\, > we'd find out about it when perl's test suite is run\. > > Cheers\, > Rob > > On Tue\, Apr 16\, 2019 at 7​:53 AM Karl Williamson via RT > \<perlbug\-followup@​perl\.org \<mailto​:perlbug\-followup@​perl\.org> \<mailto​:perlbug\-followup@​perl\.org \<mailto​:perlbug\-followup@​perl\.org>>> wrote​: > > This should be fixed by > commit 4ac6fab20b8950ee14756c6f2438809c572082cd > Author​: Karl Williamson \<khw@​cpan\.org \<mailto​:khw@​cpan\.org> \<mailto​:khw@​cpan\.org \<mailto​:khw@​cpan\.org>>> > Date​: Mon Apr 15 11​:10​:31 2019 \-0600 > > PATCH​: \[perl \#133945\] Perl\_strtod failures > > This commit wraps Perl\_strtod\(\) in macros that cause the > proper radix > character to be used\. > > \-\- > Karl Williamson > > \-\-\- > via perlbug​: queue​: perl5 status​: open > https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133945 >
I see that line 6555 of perl.h is presently: #define Perl_strotod(s\, e) \
I wonder if that was meant to be: #define Perl_strtod(s\, e) \
(I'll test it.)
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 10:26 PM sisyphus \sisyphus359@​gmail\.com wrote:
James\, Does the following behave as desired ?
##################### use warnings; use Inline C => \<\<'EOC'; int foo() { #ifdef Perl_strtod return 0; #else return 1; #endif } EOC exit(foo()); ####################
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 9:59 PM James E Keenan \jkeenan@​pobox\.com wrote:
On 4/16/19 4:53 AM\, sisyphus wrote:
Something in the last couple of days has definitely caused a reversion to use of perl's atof().
This Inline::C script: ######################## use warnings; use Inline C => \<\<'EOC'; void foo() { #ifdef Perl_strtod printf("Perl_strtod defined\n"); #else printf("Perl_strtod NOT defined\n"); #endif } EOC foo(); ########################
I can confirm this result on Linux.
Is there any way your C program could be rewritten such that we get a Perl exit 0 on defined and a Perl exit 1 on NOT defined? If we had that\, then we could plug it into Porting/bisect.pl.
reports (on all of my Windows and Linux builds) that current blead has Perl_strtod NOT defined. If Perl_strtod is not defined then I don't think that Perl_strtod can be assigning the values - it must surely be perl's atof() that's doing the assigning.
My -Dusequadmath builds are also afflicted with the issue (as they now also do not define Perl_strtod). That's not a reversion - this is the first time ever that quadmath builds have used perl's atof()\, and the result is not pretty.
Anyway - perhaps it's not your commit that's the culprit. It has to be something fairly recent because I built blead a couple of days ago and it was fine. (My builds do check that strtod/strtold/strtoflt128 are being used.) I haven't even yet glanced at the current perl source. I've instead been trying to gauge the scope of the breakage - which is something that took me far longer than it ought.
I'll prepare and post that patch to posix.t tonight\, and try to get my head around the perl source tomorrow.
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 1:50 PM Karl Williamson \< public@khwilliamson.com \mailto​:public@​khwilliamson\.com> wrote:
On 4/15/19 8​:39 PM\, sisyphus wrote​: > Unfortunately this latest commit > \(4ac6fab20b8950ee14756c6f2438809c572082cd\) gets us back to
assigning
values incorrectly. (Perl's test suite will not presently detect this.) I guess we've now somehow gone back to using perl's atof() function for assignment of floating point values. At least\, it seems that the values being assigned are now the same as the values that perl's atof() assigns.
I re\-inspected the patch and don't see anyway that it could have
made this switcheroo.
A quick check that will catch the problem is to run something like: $ perl -MPOSIX -le 'print "wtf" if POSIX::strtod("8.87359152e-6") != 8.87359152e-6;'
When nvtype is 'double\, the value of 8.87359152e-6 is assigned incorrectly by perl's atof on a number of platforms\, including Windows and Linux - so it's a good value to test.
Perhaps we should even add that test to the POSIX test suite ? We'd need to test a different value for -Duselongdouble builds - I'll write a patch for posix.t and submit it later today in a separate bug report.
That sounds good\. > That way\, if Perl\_strtod\(\) is defined but perl's atof\(\) is being used\, > we'd find out about it when perl's test suite is run\. > > Cheers\, > Rob > > On Tue\, Apr 16\, 2019 at 7​:53 AM Karl Williamson via RT > \<perlbug\-followup@​perl\.org \<mailto​:perlbug\-followup@​perl\.org> \<mailto​:perlbug\-followup@​perl\.org \<mailto​:perlbug\-followup@​perl\.org>>> wrote​: > > This should be fixed by > commit 4ac6fab20b8950ee14756c6f2438809c572082cd > Author​: Karl Williamson \<khw@​cpan\.org \<mailto​:khw@​cpan\.org \<mailto​:khw@​cpan\.org \<mailto​:khw@​cpan\.org>>> > Date​: Mon Apr 15 11​:10​:31 2019 \-0600 > > PATCH​: \[perl \#133945\] Perl\_strtod failures > > This commit wraps Perl\_strtod\(\) in macros that cause
the
proper radix character to be used\. \-\- Karl Williamson \-\-\- via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133945
On 4/16/19 7:06 AM\, sisyphus wrote:
I see that line 6555 of perl.h is presently: #define Perl_strotod(s\, e) \
I wonder if that was meant to be: #define Perl_strtod(s\, e) \
(I'll test it.)
Yes\, that's the typo. But fixing it opens a can of worms. Which I believe I have fixed in https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/khw-strtod
Please check it out.
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 10:26 PM sisyphus \<sisyphus359@gmail.com \mailto​:sisyphus359@​gmail\.com> wrote:
James\, Does the following behave as desired ? \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\# use warnings; use Inline C => \<\<'EOC'; int foo\(\) \{ \#ifdef Perl\_strtod return 0; \#else return 1; \#endif \} EOC exit\(foo\(\)\); \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\# Cheers\, Rob On Tue\, Apr 16\, 2019 at 9​:59 PM James E Keenan \<jkeenan@​pobox\.com \<mailto​:jkeenan@​pobox\.com>> wrote​: On 4/16/19 4​:53 AM\, sisyphus wrote​: > Something in the last couple of days has definitely caused a reversion > to use of perl's atof\(\)\. > > This Inline​::C script​: > \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\# > use warnings; > use Inline C => \<\<'EOC'; > void foo\(\) \{ > \#ifdef Perl\_strtod > printf\("Perl\_strtod defined\\n"\); > \#else > printf\("Perl\_strtod NOT defined\\n"\); > \#endif > \} > EOC > foo\(\); > \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\# > I can confirm this result on Linux\. Is there any way your C program could be rewritten such that we get a Perl exit 0 on defined and a Perl exit 1 on NOT defined? If we had that\, then we could plug it into Porting/bisect\.pl \<http​://bisect\.pl>\. > reports \(on all of my Windows and Linux builds\) that current blead has > Perl\_strtod NOT defined\. > If Perl\_strtod is not defined then I don't think that Perl\_strtod can be > assigning the values \- it must surely be perl's atof\(\) that's doing the > assigning\. > > My \-Dusequadmath builds are also afflicted with the issue \(as they now > also do not define Perl\_strtod\)\. That's not a reversion \- this is the > first time ever that quadmath builds have used perl's atof\(\)\, and the > result is not pretty\. > > Anyway \- perhaps it's not your commit that's the culprit\. > It has to be something fairly recent because I built blead a couple of > days ago and it was fine\. \(My builds do check that > strtod/strtold/strtoflt128 are being used\.\) > I haven't even yet glanced at the current perl source\. I've instead been > trying to gauge the scope of the breakage \- which is something that took > me far longer than it ought\. > > I'll prepare and post that patch to posix\.t tonight\, and try to get my > head around the perl source tomorrow\. > > Cheers\, > Rob > > On Tue\, Apr 16\, 2019 at 1​:50 PM Karl Williamson \<public@​khwilliamson\.com \<mailto​:public@​khwilliamson\.com> > \<mailto​:public@​khwilliamson\.com \<mailto​:public@​khwilliamson\.com>>> wrote​: > > On 4/15/19 8​:39 PM\, sisyphus wrote​: > > Unfortunately this latest commit > > \(4ac6fab20b8950ee14756c6f2438809c572082cd\) gets us back to assigning > > values incorrectly\. \(Perl's test suite will not presently detect > this\.\) > > I guess we've now somehow gone back to using perl's atof\(\) > function for > > assignment of floating point values\. > > At least\, it seems that the values being assigned are now the > same as > > the values that perl's atof\(\) assigns\. > > I re\-inspected the patch and don't see anyway that it could have made > this switcheroo\. > > > > A quick check that will catch the problem is to run something like​: > > $ perl \-MPOSIX \-le 'print "wtf" if POSIX​::strtod\("8\.87359152e\-6"\) \!= > > 8\.87359152e\-6;' > > > > When nvtype is 'double\, the value of 8\.87359152e\-6 is assigned > > incorrectly by perl's atof on a number of platforms\, including > Windows > > and Linux \- so it's a good value to test\. > > > > Perhaps we should even add that test to the POSIX test suite ? > > We'd need to test a different value for \-Duselongdouble builds \- > I'll > > write a patch for posix\.t and submit it later today in a separate > bug > > report\. > > That sounds good\. > > > That way\, if Perl\_strtod\(\) is defined but perl's atof\(\) is being > used\, > > we'd find out about it when perl's test suite is run\. > > > > Cheers\, > > Rob > > > > On Tue\, Apr 16\, 2019 at 7​:53 AM Karl Williamson via RT > > \<perlbug\-followup@​perl\.org \<mailto​:perlbug\-followup@​perl\.org> \<mailto​:perlbug\-followup@​perl\.org \<mailto​:perlbug\-followup@​perl\.org>> > \<mailto​:perlbug\-followup@​perl\.org \<mailto​:perlbug\-followup@​perl\.org> > \<mailto​:perlbug\-followup@​perl\.org \<mailto​:perlbug\-followup@​perl\.org>>>> wrote​: > > > > This should be fixed by > > commit 4ac6fab20b8950ee14756c6f2438809c572082cd > > Author​: Karl Williamson \<khw@​cpan\.org \<mailto​:khw@​cpan\.org> \<mailto​:khw@​cpan\.org \<mailto​:khw@​cpan\.org>> > \<mailto​:khw@​cpan\.org \<mailto​:khw@​cpan\.org> \<mailto​:khw@​cpan\.org \<mailto​:khw@​cpan\.org>>>> > > Date​: Mon Apr 15 11​:10​:31 2019 \-0600 > > > > PATCH​: \[perl \#133945\] Perl\_strtod failures > > > > This commit wraps Perl\_strtod\(\) in macros that cause the > > proper radix > > character to be used\. > > > > \-\- > > Karl Williamson > > > > \-\-\- > > via perlbug​: queue​: perl5 status​: open > > https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133945 > > >
On Tue\, 16 Apr 2019 16:43:42 GMT\, public@khwilliamson.com wrote:
On 4/16/19 7:06 AM\, sisyphus wrote:
I see that line 6555 of perl.h is presently: #define Perl_strotod(s\, e) \
I wonder if that was meant to be: #define Perl_strtod(s\, e) \
(I'll test it.)
Yes\, that's the typo. But fixing it opens a can of worms. Which I believe I have fixed in https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/khw- strtod
Please check it out.
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 10:26 PM sisyphus \<sisyphus359@gmail.com \mailto​:sisyphus359@​gmail\.com> wrote:
James\, Does the following behave as desired ?
##################### use warnings; use Inline C => \<\<'EOC'; int foo() { #ifdef Perl_strtod return 0; #else return 1; #endif } EOC exit(foo()); ####################
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 9:59 PM James E Keenan \<jkeenan@pobox.com \mailto​:jkeenan@​pobox\.com> wrote:
On 4/16/19 4:53 AM\, sisyphus wrote:
Something in the last couple of days has definitely caused a reversion to use of perl's atof().
This Inline::C script: ######################## use warnings; use Inline C => \<\<'EOC'; void foo() { #ifdef Perl_strtod printf("Perl_strtod defined\n"); #else printf("Perl_strtod NOT defined\n"); #endif } EOC foo(); ########################
I can confirm this result on Linux.
Is there any way your C program could be rewritten such that we get a Perl exit 0 on defined and a Perl exit 1 on NOT defined? If we had that\, then we could plug it into Porting/bisect.pl \<http://bisect.pl>.
> reports \(on all of my Windows and Linux builds\) that > current
blead has
Perl_strtod NOT defined. If Perl_strtod is not defined then I don't think that Perl_strtod can be assigning the values - it must surely be perl's atof() that's doing the assigning.
My -Dusequadmath builds are also afflicted with the issue (as they now also do not define Perl_strtod). That's not a reversion - this is the first time ever that quadmath builds have used perl's atof()\, and the result is not pretty.
Anyway - perhaps it's not your commit that's the culprit. It has to be something fairly recent because I built blead a couple of days ago and it was fine. (My builds do check that strtod/strtold/strtoflt128 are being used.) I haven't even yet glanced at the current perl source. I've instead been trying to gauge the scope of the breakage - which is something that took me far longer than it ought.
I'll prepare and post that patch to posix.t tonight\, and try to get my head around the perl source tomorrow.
Cheers\, Rob
On Tue\, Apr 16\, 2019 at 1:50 PM Karl Williamson \<public@khwilliamson.com \mailto​:public@​khwilliamson\.com \<mailto:public@khwilliamson.com \mailto​:public@​khwilliamson\.com>> wrote:
On 4/15/19 8:39 PM\, sisyphus wrote: > Unfortunately this latest commit > (4ac6fab20b8950ee14756c6f2438809c572082cd) gets us back to assigning > values incorrectly. (Perl's test suite will not presently detect this.) > I guess we've now somehow gone back to using perl's atof() function for > assignment of floating point values. > At least\, it seems that the values being assigned are now the same as > the values that perl's atof() assigns.
I re-inspected the patch and don't see anyway that it could have made this switcheroo. > > A quick check that will catch the problem is to run something like: > $ perl -MPOSIX -le 'print "wtf" if POSIX::strtod("8.87359152e-6") != > 8.87359152e-6;' > > When nvtype is 'double\, the value of 8.87359152e-6 is assigned > incorrectly by perl's atof on a number of platforms\, including Windows > and Linux - so it's a good value to test. > > Perhaps we should even add that test to the POSIX test suite ? > We'd need to test a different value for -Duselongdouble builds - I'll > write a patch for posix.t and submit it later today in a separate bug > report.
That sounds good.
> That way\, if Perl_strtod() is defined but perl's atof() is being used\, > we'd find out about it when perl's test suite is run. > > Cheers\, > Rob > > On Tue\, Apr 16\, 2019 at 7:53 AM Karl Williamson via RT > \<perlbug-followup@perl.org \mailto​:perlbug\-followup@​perl\.org \<mailto:perlbug-followup@perl.org \mailto​:perlbug\-followup@​perl\.org> \<mailto:perlbug-followup@perl.org \mailto​:perlbug\-followup@​perl\.org \<mailto:perlbug-followup@perl.org \mailto​:perlbug\-followup@​perl\.org>>> wrote: > > This should be fixed by > commit 4ac6fab20b8950ee14756c6f2438809c572082cd > Author: Karl Williamson \<khw@cpan.org \mailto​:khw@​cpan\.org \<mailto:khw@cpan.org \mailto​:khw@​cpan\.org> \<mailto:khw@cpan.org \mailto​:khw@​cpan\.org \<mailto:khw@cpan.org \mailto​:khw@​cpan\.org>>> > Date: Mon Apr 15 11:10:31 2019 -0600 > > PATCH: [perl #133945] Perl_strtod failures > > This commit wraps Perl_strtod() in macros that cause the > proper radix > character to be used. > > -- > Karl Williamson > > --- > via perlbug: queue: perl5 status: open > https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133945 >
With a perl built in the smoke-me/khw_strtod branch\, I run Sisyphus's program and get:
##### [khw-strtod] 506 $ ./bin/perl -Ilib ~/learn/perl/p5p/133945-strtod.pl Perl_strtod NOT defined #####
Is that the expected result?
Thank you very much. -- James E Keenan (jkeenan@cpan.org)
Thank you for filing this report. You have helped make Perl better.
With the release today of Perl 5.30.0\, this and 160 other issues have been resolved.
Perl 5.30.0 may be downloaded via: https://metacpan.org/release/XSAWYERX/perl-5.30.0
If you find that the problem persists\, feel free to reopen this ticket.
@khwilliamson - Status changed from 'pending release' to 'resolved'
Migrated from rt.perl.org#133945 (status was 'resolved')
Searchable as RT133945$