| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
The mktables generated tables are well-formed, already sorted, and with
no extra items such as "+utf8::foo". Thus we don't have to do these
operations on them, but they are required on user-defined properties,
and should $list be passed in as a parameter.
This patch moves the code that does this to just the user-defined area
|
|
|
|
|
| |
This new test makes sure that a regular expression that forward
references a user-defined property works.
|
| |
|
|
|
|
| |
And the reordering for clarity of one test
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This way, we can begin summarizing now, rather than
summarize everything during the final release
period.
Also, note the new "Future Deprecations" section,
in which we can, where possible, announce that we
feel likely to formally deprecate things in the
next major release.
|
|
|
|
|
|
|
|
| |
It's possible that the referencing SV is being freed partway through the
freeing of reference target. If this happens, the backreferences array of
the target has already been freed, and so svp will be NULL. If this is the
case, do nothing and return. Previously, this condition was not recognised
and the code would panic.
|
|
|
|
|
|
|
|
|
|
| |
During global destruction, it's possible for the array containing
backreferences to be freed before the SV that owns it. If this happens, don't
mistake it for a scalar backreference stored directly, and then get confused
and panic because things seem inconsistent.
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-12/msg00039.html
gives more information.
|
|
|
|
|
|
| |
If panicing with a croak(), include in the panic message the values which
caused the croak. This reveals something about the cause of the panic, and
more subtly, which of the two possible panic locations this is.
|
|
|
|
| |
This was brought up in bug #77388.
|
|
|
|
|
| |
name is only set when there is no gv. As of a couple of commits ago,
tmpsv is only used in that else block where it is set.
|
|
|
|
|
|
| |
They just need to pick up the _ filehandle in stacked mode, like the
other ops (which actually rely on my_stat[_flags] to do it). This
apparently was forgotten when stacked filetests were added.
|
|
|
|
|
|
| |
This is something I broke carelessly with commit 094a3eec8.
No, this does not fix bug #77388.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise we might get a crash. cGVOP_gv is only valid when the
OPf_REF flag is set. In either case, gv already holds the GV we
want anyway.
This code has been buggy this way since this commit:
commit 5f05dabc4054964aa3b10f44f8468547f051cdf8
Author: Perl 5 Porters <perl5-porters@africa.nicoh.com>
Date: Thu Dec 19 16:44:00 1996 +1200
[inseparable changes from patch from perl5.003_11 to perl5.003_12]
but apparently has not actually caused a crash until just now.
I was trying to add a test for another bug (fixed in the next commit),
and it happened to trigger this one. My attempt to reduce this to
something small and reproducible failed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mentioning $& in a program slows everything down, because it force
regular expressions to do a pre-match copy.
It used to happen for any symbol named &, e.g., @& and %&. This was
changed in commit b4a9608f339, but that commit did not take into
account that the code path in question is only followed on creation of
the *& glob.
It should still be applying magic to $&, even if it is not setting
PL_sawampersand. The other place in gv_fetchpvn_flags that magical-
ises scalars (which currently handles %- %+ %! $] and @ISA), should
also turn on PL_sawampersand for $&.
All of the above applies to $' and $` as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After autovivification, perl should not assume that the value it has
assigned to a magical scalar is the one that would have been returned.
The result of this assumption is that any tie class that copies things
assigned to it will cause autovivification to assign to a temporary
aggregate without warning, in cases like this:
$tied{nonexistent}{foo} = 7;
The hash implicitly assigned to $tied{nonexistent} ends up being freed
after the =7 assignment.
This commit changes autovivification to do FETCH immediately after
doing STORE.
This required changing some recently-added tests in gmagic.t.
Without this change, you end up with horrific workarounds (using B.pm
to get the reference count), like the one in JE::Object (which I’m
pasting here, in case it has changed by the time you read this):
sub STORE {
my($self, $key, $val) = @_;
my $global = $self->global;
if(ref $val eq 'HASH' && !blessed $val
&& !%$val && svref_2object($val)->REFCNT == 2) {
$val = tie %$val, __PACKAGE__, __PACKAGE__->new(
$global);
} elsif (ref $val eq 'ARRAY' && !blessed $val && !@$val &&
svref_2object($val)->REFCNT == 2) {
require JE::Object::Array;
$val = tie @$val, 'JE::Object::Array',
JE::Object::Array->new($global);
}
$self->prop($key => $global->upgrade($val))
}
|
|
|
|
|
|
|
| |
It seemed to imply that CORE:: syntax was introduced in 5.16. What it
was supposed to say was that CORE:: breaking through the feature.pm
barrier was introduced in 5.16. (Which sounds a little odd, as 5.16
is still in the future, but whatever.)
|
|
|
|
|
|
|
| |
Commit 60edcf09a was supposed to make things less buggy, but putting
the ENTER/LEAVE in h_freeentries was a mistake, as both hv_undef and
hv_clear still access the hv after calling h_freeentries. Why it
didn’t crash for me is anyone’s guess.
|
|
|
|
|
| |
This test includes an explosive class, that overload::Overloaded
should be able to handle.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It’s possible, and too easy, for classes to define a can method to
deal with AUTOLOAD, without taking overloading into account. Since
AUTOLOAD is the main reason for overriding can, and since overloading
does not respect autoloading, can overrides should not be expected to
deal with it.
Since overload.pm already has a mycan function that fits this purpose,
this commit changes Overloaded to use that.
The test includes an example of a class structure that the previous
Overloaded implementation could not handle.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> > Actually, the simplest solution seem to be to put the av or hv on
> > the mortals stack in pp_aassign and pp_undef, rather than in
> > [ah]v_undef/clear.
>
> This makes me nervous. The tmps stack is typically cleared only on
> statement boundaries, so we run the risks of
>
> * user-visible delaying of freeing elements;
> * large tmps stack growth might be possible with
> certain types of loop that repeatedly assign to an array without
> freeing tmps (eg map? I think I fixed most map/grep tmps leakage
> a
> while back, but there may still be some edge cases).
>
> Surely an ENTER/SAVEFREESV/LEAVE inside pp_aassign is just as
> efficient,
> without any attendant risks?
>
> Also, although pp_aassign and pp_undef are now fixed, the
> [ah]v_undef/clear functions aren't, and they're part of the public API
> that can be called independently of pp_aassign etc. Ideally they
> should
> be fixed (so they don't crash in mid-loop), and their documentation
> updated to point out that on return, their AV/HV arg may have been
> freed.
This commit takes care of the first part; it changes pp_aassign to use
ENTER/SAVEFREESV/LEAVE and adds the same to h_freeentries (called both
by hv_undef and hv_clear), av_undef and av_clear.
It effectively reverts the C code part of 9f71cfe6ef2.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only uses of USE_LEFT in core now occur when SvGETMAGIC has
already been called. So returning true for magical SVs is not neces-
sary. In fact, it was never correct.
Also, the code in do_vop (which handles bitwise operations on strings)
to avoid an uninitialized warning had the same buggy SvGMAGICAL check.
Now, the warning from $uninit += 1 is suppressed for all undefined
vars, not just amagical ones.
This causes 6 to-do tests in assignwarn.t to pass.
|
|
|
|
|
|
| |
These are undocumented and unused on CPAN and in the core.
The core now uses _nomg variants.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current definition of SAVE_DEFSV doesn’t take reference count-
ing into account. Every instance of it in the perl core is buggy
as a result.
Most are also followed by DEFSV_set, which is likewise buggy.
This commit implements SAVE_DEFSV in terms of save_gp and
SAVEGENERICSV if PERL_CORE is defined. save_gp and SAVEGENERICSV are
what local(*_) = \$foo uses. Changing the definition for XS code is
probably too risky this close to 5.16. It should probably be changed
later, though.
DEFSV_set is now changed to do reference counting too.
|
|
|
|
| |
for parenthetical omissions.
|
|
|
|
|
|
|
|
|
|
| |
These 4 functions have been replaced by variants to_utf8_foo_flags(),
but for XS code that called the old ones in the Perl_to_utf8_foo()
forms, backwards compatibility versions need to be created.
For calls of just the to_utf8_foo() forms, macros have been used to
automatically call the new forms without the performance penalty of
going through the compatibility functions.
|
|
|
|
|
| |
The 'd' flag doesn't mean that the documentation has to be even in the
same file as the source for that function; just somewhere in the source.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
[DELTA]
5.0150037 Sun 8 Jan 2012 21:24:39 +0100
* Better XML parsing recommendations (apeiron)
* Remove various old questions & update a few (ranguard)
* Change auto generate of questions a bit (ranguard)
* Autogenerate question index in perlfaq.pod (doherty)
* Cleanups / typos, updating nested expressions (dami, reviewed by schwern)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This little snippet:
sub TIESCALAR{bless[]}
sub STORE{}
tie $^H{foo}, '';
$^H{foo} = 1;
delete $^H{foo};
dies with ‘Can't locate object method "DELETE"...’.
This bug was introduced for %^H by commit b3ca2e834c, but it is actu-
ally an older bug that already affected %ENV before that.
Clear-magic on a scalar is only called when it is an element of a mag-
ical aggregate.
For hashes, this clear-magic is called whenever the hash itself
is RMAGICAL.
Tied scalars and elements of tied aggregates use the same magic vta-
ble, under the assumption that mg_clear will never be called on a tied
scalar. That assumption is wrong.
Commit b3ca2e834c is the one that made %^H magical, which is why it
caused this problem for %^H.
The obvious solution, giving tied scalars their own vtable, is not as
simple as it sounds, because then tied scalars are no longer RMAGICAL,
and at least some of the tie code assumes that they are.
So the easiest fix is to skip the DELETE call in Perl_magic_clearpack
if the type of magic is PERL_MAGIC_tiedscalar.
|
| |
|
|
|
|
|
|
|
| |
It can return via 'goto &sub', but not via 'goto LABEL'.
The docs originally just said 'via goto'
See [perl #44367].
|
| |
|
|
|
|
|
| |
It's now twelve years since Y2K, so the documentation should not make
such a fuss about it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Tue Mar 08 07:26:35 2011, thospel wrote:
> #!/usr/bin/perl -l
> use Data::Dumper;
> use Scalar::Util qw(weaken);
> our @ISA;
>
> for (1..2) {
> @ISA = qw(Foo);
> weaken($a = \@ISA);
> weaken($a = \$ISA[0]);
> print STDERR Dumper(\@ISA);
> }
>
> This prints:
> $VAR1 = [
> 'Foo'
> ];
> $VAR1 = [
> 'Foo',
> \$VAR1->[0]
> ];
>
> So the first time it's the expected @ISA, but the second time round it
> automagically added a reference to to the first ISA element
>
> (bug also exists in blead)
Shorter:
#!/usr/bin/perl -l
use Scalar::Util qw(weaken);
weaken($a = \@ISA);
@ISA = qw(Foo);
use Devel::Peek; Dump \@ISA;
weaken($a = \$ISA[0]);
print scalar @ISA; # prints 2
The dump shows the problem. backref magic is being copied to the ele-
ment. Put the magic in a different order, and everything is fine:
#!/usr/bin/perl -l
use Scalar::Util qw(weaken);
weaken($a = $b = []);
*ISA = $a;
@ISA = qw(Foo);
use Devel::Peek; Dump \@ISA;
weaken($a = \$ISA[0]);
print scalar @ISA; # prints 2
This code in av_store is so wrong:
if (SvSMAGICAL(av)) {
const MAGIC* const mg = SvMAGIC(av);
if (val != &PL_sv_undef) {
sv_magic(val, MUTABLE_SV(av), toLOWER(mg->mg_type), 0, key);
}
if (PL_delaymagic && mg->mg_type == PERL_MAGIC_isa)
PL_delaymagic |= DM_ARRAY_ISA;
else
mg_set(MUTABLE_SV(av));
}
It doesn’t follow the magic chain at all. So anything magic could get
attached to the @ISA array, and that will be copied to the element
instead of isa magic.
Notice that MUTABLE_SV(av) is the second argument to sv_magic, so
mg->mg_obj for the element always points back to the array.
Since backref magic’s mg->mg_obj points to the backrefs array, @ISA
ends up being used as this element’s backrefs array.
What if arylen_p gets copied instead? Let’s see:
$#ISA = -1;
@ISA = qw(Foo);
$ISA[0] = "Bar";
main->ber;
sub Bar::ber { warn "shave" }
__END__
Can't locate object method "ber" via package "main" at - line 7.
I’ve fixed this by making av_store walk the magic chain, copying any
magic for which toLOWER(mg->mg_type) != mg->mg_type.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In pp_undef and pp_aassign, we should put the av or hv that is being
cleared on the mortals stack (with an increased refcount), so that
destructors fired during the clearing do not free the av or hv.
I was going to put this in av_undef, etc., but pp_aassign also needs
to access the aggregate after clearing it. We still get a crash with
that approach.
Putting the aggregate on the mortals stack in av_undef, av_clear and
h_freeentries would work, too, but might cause the aggregate to leak
too far. That may cause problems, e.g., if it is %^H, because it may
last until the end of the current compilation unit.
Directly inside a runloop (in a pp function), it should be OK to use
the mortals stack, as it *will* be cleared ‘soon’. This seems the
least intrusive approach.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I couldn't stand the way the documenation for `split' was written;
it felt like a kludge of broken English dumped into a messy pile by
several people, each of whom was unaware of the other's work.
This variation completes sentences, adds new ones, rearranges ideas,
expands on ideas, simplifies and unifies examples, and includes more
cross references.
While the original text seemed to be written in a way that touched upon
the arguments in reverse order (which did have a hint of elegance), this
version attempts to provide the reader with the most useful information
upfront.
Thanks to Brad Baxter and Thomas R. Sibley for their constructive
criticism.
[Modified by the committer to incorporate suggestions from Aristotle
Pagaltzis and Tom Christiansen.]
|
| |
|
|
|
|
| |
do not test them as if they were Pod we ship
|
| |
|