Front page | perl.perl5.porters |
Postings from February 2018
On 17 Feb 2018 21:36, "Father Chrysostomos via RT" <
perlbug-followup@perl.org> wrote:
On Fri, 16 Feb 2018 18:53:47 -0800, demerphq wrote:
> > It is unfortunate that so many critical functions and checks in Perl
> > require namespace mutations, but that's how things work, and imo not
> > touching other namespaces has a *much* lower priority than Carp working
> > correctly and not segfaulting.
Why cannot we have both? You are being vague
Carp incorrectly assumes that the only way you can have an overloaded
object is if you have loaded overload.pm.
Which means that this segfaults due to stack overflow:
perl -MCarp -E 'my $p = "OverloadedInXS"; *{$p."::(("} = sub{};
*{$p.q!::(""!} = sub { Carp::cluck "<My Stringify>" }; sub {
Carp::cluck("") }->(bless {}, $p);'
See #132828.
To fix that without loading overload.pm I would have to more or less
extract a nice chunk of the internals of overload.pm into Carp.
But I am curious why you feel I need to defend making Carp.pm use a module.
I feel the onus should be the other way around, it should be on you, or any
others who feel Carp should not load modules to explain why Carp is such a
special flower.
We have no less than 4 different subs/mechanisms that are loaded like this:
$ grep _fetch_sub dist/Carp/lib/Carp.pm
sub _fetch_sub { # fetch sub without autovivifying
if(defined(my $sub = _fetch_sub utf8 => 'is_utf8')) {
if(defined(my $sub = _fetch_sub utf8 => 'downgrade')) {
(_fetch_sub B => 'svref_2object' or return '')
my $sub = _fetch_sub(overload => 'StrVal');
Some of them appear to be related to back-compat, but some of them are
just egregious reimplementation of another modules functionality for the
purpose of avoiding that module:
# The downgrade() function defined here is to be used for attempts to
# downgrade where it is acceptable to fail. It must be called with a
# second argument that is a true value.
BEGIN {
if(defined(my $sub = _fetch_sub utf8 => 'downgrade')) {
*downgrade = \&{"utf8::downgrade"};
} else {
*downgrade = sub {
my $r = "";
my $l = length($_[0]);
for(my $i = 0; $i != $l; $i++) {
my $o = ord(substr($_[0], $i, 1));
return if $o > 255;
$r .= chr($o);
}
$_[0] = $r;
};
}
}
I dont see any explanation for these shenanigans in the module, and instead
of "playing along" with some unstated justification for this and unrolling
a large part of overload.pm innards into Carp, I plan to just use
overload.pm and break this expectation.
Around the same time I was thinking about this Zefram then bumped
into/mentioned this issue in this ticket, and I figured I would raise my
objections to the premise and get a dialog going about why this is even
necessary.
If there is a good reason for these measures then I would expect it to be
documented in Carp.pm, since it isnt documented I assume there isn't a good
reason, and if there isn't a good reason then we should stop caring about
it at all, and maybe rip out the complicated and inefficient and
duplicative logic.
So if there is a good reason please explain before I waste my time. On the
other hand, if there isn't a good reason lets stop wasting our time with
trying to support this objective.
Why should it matter if Carp.pm unilaterally loaded overload.pm when first
used?
For that matter, why should Carp be lugging around code to support 5.6 when
we are preparing to release 5.28?
cheers,
Yves
.
Thread Previous
|
Thread Next