Front page | perl.perl5.porters |
Postings from March 2014
Re: Perl 5.20.0 Blockers, 2014-03-24 [perl #121317]
Thread Previous
|
Thread Next
From:
Karl Williamson
Date:
March 31, 2014 04:50
Subject:
Re: Perl 5.20.0 Blockers, 2014-03-24 [perl #121317]
Message ID:
5338F43F.4080807@khwilliamson.com
On 03/30/2014 09:58 PM, Karl Williamson wrote:
> On 03/30/2014 11:38 AM, Slaven Rezic wrote:
>> I suspect that every CPAN module using strtod/sprintf indirectly through
>> a shared library is broken.
>
> I think you didn't understand my previous post on this
> <53275EB2.4000809@khwilliamson.com>. These modules were already broken;
> it's just that their breakage didn't surface very often prior to the
> blamed patch.
>
> It's like the hash key order randomization change. Most modules that
> "broke" as a result of the change were already broken. It's just that
> their tests and typical usage didn't cause the hashes to grow enough to
> cause an hsplit(), which, when it happens, causes the key order to
> change, IIRC. The change, besides being necessary for security reasons,
> did the maintainers a favor by exposing a problem that could
> occasionally occur in the field and would be very hard to reproduce and
> debug.
>
> In my post on this, I show how to easily get the same breakage symptoms
> on earlier Perl releases as the blamed commit gives in 5.19.
>
> The blamed commit is not necessary for security, so we as a project
> might decide that it's not worth fixing these bugs, and to permanently
> revert the patch, documenting the issue. But that is very different
> from the idea that this patch "broke" modules, and I believe it's
> important to keep that distinction in mind when making whatever decision
> gets made.
>
> "The truth shall set you free, but first it will make you miserable"
> -- origin disputed, often (mis-)attributed to U.S. president James
> Garfield, who BTW came up with an original proof of the
> Pythagorean theorem
>
>
>
>
Having thought about this a little more, I have yet another idea:
1) Revert the commit for 5.20.
2) In 5.21, change POSIX::setlocale() so that it always leaves the
LC_NUMERIC locale as "C", but sets an interpreter variable (which
already is done BTW) to indicate what locale to use when doing
LC_NUMERIC operations within the scope of "use locale". The core
already wraps all such operations it performs (unless I've missed any)
so that it uses the correct locale based on that flag, and "use locale"
scope. Thus pure perl code is unaffected.
3) This would mean that all libc calls from XS would normally get a dot
radix, and the modules that Slaven has given would be automatically
fixed from those bugs I said existed in 5.18 and earlier.
4) There are undoubtedly XS modules that depend on the radix not being
dot when a setlocale asking for such is executed. But judging from the
responses here, these are far fewer than those that always want a dot.
By doing the change very early in 5.21, we find out for sure. Anyway,
such modules would have to save/set/restore LC_NUMERIC around their
non-dot need. There are macros in perl.h that manage this for you.
Some of these have been around and been used by the core and POSIX::XS
since at least 1996, v5.003.
5) POSIX::strtod() has for a long time assumed that the LC_NUMERIC
locale was possibly wrongly C, and used the macros to change it to what
the interpreter variable says it should be (but there was a bug until
5.19 in which it failed to change it back). There are other POSIX::
functions that should do the same. Maybe only localeconv().
This would probably mean we wouldn't deprecate Gconvert, but as I
suggested earlier in the [perl #121317] thread, we document those macros
(for the first time).
Thread Previous
|
Thread Next