Skip Menu |
Report information
Id: 133945
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: int32 <dmitry [at] karasik.eu.org>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: medium
Type: core
Perl Version: 5.29.2
Fixed In: (no value)



Date: Wed, 20 Mar 2019 18:58:04 +0100
From: dmitry [...] karasik.eu.org
To: perlbug [...] perl.org
Subject: ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
Download (untitled) / with headers
text/plain 4.8k
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] ----------------------------------------------------------------- --- Flags: category=core severity=medium --- This perlbug was built using Perl 5.29.3 - Wed Mar 20 18:13:09 CET 2019 It is being executed now by Perl 5.29.2 - Wed Mar 20 18:25:02 CET 2019. Site configuration information for perl 5.29.2: Configured by dk at Wed Mar 20 18:25:02 CET 2019. Summary of my perl5 (revision 5 version 29 subversion 1) configuration: Commit id: c7ea9f039c0e7c2333adfcb3b9f1e3f2b25693a1 Platform: osname=linux osvers=4.15.0-45-generic archname=x86_64-linux uname='linux kraken 4.15.0-45-generic #48-ubuntu smp tue jan 29 16:28:13 utc 2019 x86_64 x86_64 x86_64 gnulinux ' config_args='' hint=previous useposix=true d_sigaction=define useithreads=undef usemultiplicity=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='cc' ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' optimize='-O2' cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' ccversion='' gccversion='7.3.0' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long' ivsize=8 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='cc' ldflags =' -fstack-protector-strong -L/usr/local/lib' libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/lib libs=-lpthread -lnsl -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc libc=libc-2.27.so so=so useshrplib=false libperl=libperl.a gnulibc_version='2.27' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=so d_dlsymun=undef ccdlflags='-Wl,-E' cccdlflags='-fPIC' lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong' --- @INC for perl 5.29.2: lib /usr/local/lib/perl5/site_perl/5.29.9/x86_64-linux /usr/local/lib/perl5/site_perl/5.29.9 /usr/local/lib/perl5/5.29.9/x86_64-linux /usr/local/lib/perl5/5.29.9 --- Environment for perl 5.29.2: HOME=/home/dk LANG=en_US.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/dk/perl5/perlbrew/bin:/home/dk/bin:/home/dk/bin:/home/dk/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/opt/thinlinc/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/local/site/bin:/usr/local/site/sbin:/opt/ibm/db2/V9.7/bin PERLBREW_HOME=/home/dk/.perlbrew PERLBREW_ROOT=/home/dk/perl5/perlbrew PERLBREW_SHELLRC_VERSION=0.84 PERL_BADLANG (unset) SHELL=/usr/bin/zsh
Download localebug-1.00.tar.gz
application/gzip 1.7k

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
Very similar issue (fixed in 5.20.1) https://rt.perl.org/Public/Bug/Display.html?id=122105
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
On Wed, 20 Mar 2019 18:03:23 GMT, int32 wrote: Show quoted text
> 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)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Wed, 20 Mar 2019 18:03:23 GMT, int32 wrote: Show quoted text
> 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)
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
To: James E Keenan via RT <perlbug-followup [...] perl.org>
Date: Thu, 21 Mar 2019 15:20:08 +0100
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
Show quoted text
> 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. Show quoted text
> > 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 Show quoted text
> > Thank you very much. > > -- > James E Keenan (jkeenan@cpan.org)
-- Sincerely, Dmitry Karasik
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
On Thu, 21 Mar 2019 14:28:37 GMT, int32 wrote: Show quoted text
> > 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)
Date: Thu, 21 Mar 2019 16:46:04 +0100
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
To: James E Keenan via RT <perlbug-followup [...] perl.org>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
Download (untitled) / with headers
text/plain 995b
Show quoted text
> > 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 Show quoted text
> 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 Show quoted text
> > ##### > $ 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
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.4k
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: <quote> 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. </quote> 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
To: "sisyphus [...] cpan.org via RT" <perlbug-followup [...] perl.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
CC: perl5-porters [...] perl.org
Date: Fri, 22 Mar 2019 11:31:46 +0100
Download (untitled) / with headers
text/plain 918b
On Thu, Mar 21, 2019 at 08:16:52PM -0700, sisyphus@cpan.org via RT wrote: Show quoted text
> 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.perl.org/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. Show quoted text
> 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
To: Dmitry Karasik <dmitry [...] karasik.eu.org>, "sisyphus [...] cpan.org via RT" <perlbug-followup [...] perl.org>
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
Date: Fri, 22 Mar 2019 09:53:40 -0600
CC: perl5-porters [...] perl.org
On 3/22/19 4:31 AM, Dmitry Karasik wrote: Show quoted text
> 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.perl.org/Ticket/Display.html?id=122105 > > (it's buried somewhere in the discussion).
You can start way down, at https://rt.perl.org/Ticket/Display.html?id=121930#txn-1298035 Show quoted text
> > 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 Show quoted text
>
>> 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.
To: Karl Williamson <public [...] khwilliamson.com>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
CC: "sisyphus [...] cpan.org via RT" <perlbug-followup [...] perl.org>, perl5-porters [...] perl.org
Date: Fri, 22 Mar 2019 23:10:49 +0100
Download (untitled) / with headers
text/plain 423b
On Fri, Mar 22, 2019 at 09:53:40AM -0600, Karl Williamson wrote: Show quoted text
> 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
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 572b
On Fri, 22 Mar 2019 15:11:00 -0700, int32 wrote: Show quoted text
> 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
Date: Mon, 25 Mar 2019 16:30:24 +0100
CC: perl5-porters [...] perl.org
To: Karl Williamson via RT <perlbug-followup [...] perl.org>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Download (untitled) / with headers
text/plain 986b
On Sat, Mar 23, 2019 at 11:26:22AM -0700, Karl Williamson via RT wrote: Show quoted text
> 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
CC: perl5-porters [...] perl.org
Date: Mon, 25 Mar 2019 10:43:33 -0600
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
To: Dmitry Karasik <dmitry [...] karasik.eu.org>, Karl Williamson via RT <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 1.1k
On 3/25/19 9:30 AM, Dmitry Karasik wrote: Show quoted text
> 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.
CC: Karl Williamson via RT <perlbug-followup [...] perl.org>, perl5-porters [...] perl.org
Date: Tue, 26 Mar 2019 00:14:43 +0100
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
To: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 1.7k
Show quoted text
> >>> > >>> 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
Date: Mon, 15 Apr 2019 11:05:56 -0600
To: perl5-porters [...] perl.org
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
Download (untitled) / with headers
text/plain 1.8k
On 3/20/19 12:03 PM, Dmitry Karasik (via RT) wrote: Show quoted text
> # 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.perl.org/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
Date: Mon, 15 Apr 2019 21:59:09 +0200
To: karl williamson via RT <perlbug-followup [...] perl.org>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Download (untitled) / with headers
text/plain 469b
Show quoted text
> > 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
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 331b
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
From: sisyphus <sisyphus359 [...] gmail.com>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
To: "sisyphus [...] cpan.org via RT" <perlbug-followup [...] perl.org>
CC: Perl5 Porteros <perl5-porters [...] perl.org>
Date: Tue, 16 Apr 2019 12:39:15 +1000
Download (untitled) / with headers
text/plain 1.5k
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:
Show quoted text
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.perl.org/Ticket/Display.html?id=133945
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
To: sisyphus <sisyphus359 [...] gmail.com>, "sisyphus [...] cpan.org via RT" <perlbug-followup [...] perl.org>
CC: Perl5 Porteros <perl5-porters [...] perl.org>
Date: Mon, 15 Apr 2019 21:50:26 -0600
Download (untitled) / with headers
text/plain 1.9k
On 4/15/19 8:39 PM, sisyphus wrote: Show quoted text
> 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. Show quoted text
> > 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. Show quoted text
> 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.perl.org/Ticket/Display.html?id=133945 >
CC: "sisyphus [...] cpan.org via RT" <perlbug-followup [...] perl.org>, Perl5 Porteros <perl5-porters [...] perl.org>
Date: Tue, 16 Apr 2019 18:53:34 +1000
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaks float formatting under GTK
From: sisyphus <sisyphus359 [...] gmail.com>
To: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 3.3k
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:
Show quoted text
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.perl.org/Ticket/Display.html?id=133945
>

From: James E Keenan <jkeenan [...] pobox.com>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaksfloat formatting under GTK
To: perl5-porters [...] perl.org
Date: Tue, 16 Apr 2019 07:59:30 -0400
Download (untitled) / with headers
text/plain 4.2k
On 4/16/19 4:53 AM, sisyphus wrote: Show quoted text
> 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. Show quoted text
> 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.perl.org/Ticket/Display.html?id=133945 > >
>
CC: Perl5 Porteros <perl5-porters [...] perl.org>
Date: Tue, 16 Apr 2019 22:26:41 +1000
From: sisyphus <sisyphus359 [...] gmail.com>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaksfloat formatting under GTK
To: James E Keenan <jkeenan [...] pobox.com>
Download (untitled) / with headers
text/plain 4.7k
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:
Show quoted text
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.perl.org/Ticket/Display.html?id=133945
>      >
>
To: James E Keenan <jkeenan [...] pobox.com>
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaksfloat formatting under GTK
From: sisyphus <sisyphus359 [...] gmail.com>
Date: Tue, 16 Apr 2019 23:06:24 +1000
CC: Perl5 Porteros <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 5.1k

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:
Show quoted text
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.perl.org/Ticket/Display.html?id=133945
>      >
>
CC: Perl5 Porteros <perl5-porters [...] perl.org>
Date: Tue, 16 Apr 2019 10:43:16 -0600
Subject: Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaksfloat formatting under GTK
From: Karl Williamson <public [...] khwilliamson.com>
To: sisyphus <sisyphus359 [...] gmail.com>, James E Keenan <jkeenan [...] pobox.com>
Download (untitled) / with headers
text/plain 7.2k
On 4/16/19 7:06 AM, sisyphus wrote: Show quoted text
> > 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. Show quoted text
> > 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.perl.org/Ticket/Display.html?id=133945 > >      > > >
>
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 7.9k
On Tue, 16 Apr 2019 16:43:42 GMT, public@khwilliamson.com wrote: Show quoted text
> 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.perl.org/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)
Download (untitled) / with headers
text/plain 313b
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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org