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

Re: Perl 5.20.0 Blockers, 2014-03-24

Thread Previous | Thread Next
Slaven Rezic
March 31, 2014 06:15
Re: Perl 5.20.0 Blockers, 2014-03-24
Message ID:
Karl Williamson <> writes:

> 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
> <>.  These modules were already
> broken; it's just that their breakage didn't surface very often prior
> to the blamed patch.

I saw this post. But I don't see any efforts on fixing the affected
modules, i.e. sending bug reports with patches. And there is no
systematic testing to see which CPAN modules are broken.

> 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.

Your argue that these modules are broken if POSIX::setlocale is used. I
would say that POSIX::setlocale itself is broken (or the whole locale
concept in Unix). Most things in Perl have lexical or limited scope,
which is a good thing. The effects of POSIX::setlocale are global;
something you don't want to use in a large complex system. Best is to
"discourage" the use of POSIX::setlocale, and describe the possible
problems in the documentation (e.g. may change the behavior in
other parts of the code, be it perl code using, or XS code
(directly or through shared libraries) using functions which behavior
depends on the current locale).


Slaven Rezic - slaven <at> rezic <dot> de

    Berlin Perl Mongers -

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About