develooper Front page | perl.perl5.porters | Postings from March 2019

Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaksfloat formatting under GTK

Thread Previous | Thread Next
From:
Karl Williamson
Date:
March 22, 2019 15:53
Subject:
Re: [perl #133945] ce6f496d720f6206455628425320badd95b07372 breaksfloat formatting under GTK
Message ID:
c630226a-5250-3632-87db-ce7283f61ee1@khwilliamson.com
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.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
> 
> 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.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About