| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
It was never public, and was only written for the sake of pp_coreargs,
which no longer uses it.
|
| |
|
|
|
| |
As long as the lexical $_ syntax is disabled anyway, this is what they
would return.
|
| |
|
|
|
| |
As a native English speaker, I find it clearer to say that a bit vector
has a particular bit set, rather than to say that it includes that bit.
|
| | |
|
| |
|
|
|
| |
so that these constructs appear on a single output line for reader
convenience.
|
| |
|
|
| |
Removes 'the' in front of parameter names in some instances.
|
| | |
|
| |
|
|
|
| |
The majority of perlapi uses C<> to specify these things, but a few
things used I<> instead. Standardize to C<>.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Perl on MSVC6 doesnt support 64 bit ints (p5p choice not to support it)
so this macro isn't defined on MSVC6 builds, commit e59642234e hid this
mistake from non-DEBUGGING builds. The mistake is a copy paste mistake
from commit eacbb37937 . Miniperl fails at VC6 link time due to UINT64_C
symboil not being found.
..\pad.c(165) : warning C4013: 'UINT64_C' undefined; assuming extern
returning int
..\pad.c(165) : warning C4018: '!=' : signed/unsigned mismatch
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RT #124385
Parsing following a syntax error could result in a null ptr dereference.
This commit contains a band-aid that returns from Perl_cv_forget_slab() if
the cv arg is null; but the real issue is much deeper and needs a more
general fix at some point.
Basically, both the lexer and the parser use the save stack, and after an
error, they can get out of sync.
In particular:
1) when handling a double-quoted string, the lexer does an ENTER, saves
most of its current state on the save stack, then uses the literal string
as the toke source. When it reaches the end of the string, it LEAVEs,
restores the lexer state and continues with the main source.
2) Whenever the parser starts a new block or sub scope, it remembers the
current save stack position, and at end of scope, pops the save stack back
to that position.
In something like
"@{ sub {]}} }}}"
the lexer sees a double-quoted string, and saves the current lex state.
The parser sees the start of a sub, and saves PL_compcv etc. Then a parse
error occurs. The parser goes into error recovery, discarding tokens until
it can return to a sane state. The lexer runs out of tokens when toking
the string, does a LEAVE, and switches back to toking the main source.
This LEAVE restores both the lexer's and the parser's state; in particular
the parser gets its old PL_compcv restored, even though the parser hasn't
finished compiling the current sub. Later, series of '}' tokens coming
through allows the parser to finish the sub. Since PL_error_count > 0, it
discards the just-compiled sub and sets PL_compcv to null. Normally the
LEAVE_SCOPE done just after this would restore PL_compcv to its old value
(e.g. PL_main_cv) but the stack has already been popped, so PL_compcv gets
left null, and SEGVs occur.
The two main ways I can think of fixing this in the long term are
1) avoid the lexer using the save stack for long-term state storage;
in particular, make S_sublex_push() malloc a new parser object rather
than saving the current lexer state on the save stack.
2) At the end of a sublex, if PL_error_count > 0, don't try to restore
state and continue, instead just croak.
N.B. the test that this commit adds to lex.t doesn't actually trigger the
SEGV, since the bad code is wrapped in an eval which (for reasons I
haven't researched) avoids the SEGV.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An empty cpan/.dir-locals.el stops Emacs using the core defaults for
code imported from CPAN.
Committer's work:
To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed
to be incremented in many files, including throughout dist/PathTools.
perldelta entry for module updates.
Add two Emacs control files to MANIFEST; re-sort MANIFEST.
For: RT #124119.
|
| |
|
|
|
| |
(Some compilers have strange ideas about the signedness of the bool type
verses the signedness of a boolean expression like a == b).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use feature 'lexical_subs','state';
no warnings 'experimental';
my $sub = sub{
state sub sb4;
state sub a {
state $x = 42;
sub sb4 { $x; }
}
a();
print sb4(), "\n";
};
$sub->();
The output:
Bizarre copy of CODE in subroutine exit at - line 10.
The sb4 sub was trying to close over the wrong pad; namely, the one
belonging to the anonymous sub.
|
| | |
|
| |
|
|
| |
This comment, added by 3291825f, was made obsolete by 0f94cb1f.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use 5.018;
use experimental 'lexical_subs';
$::x = "global";
sub x;
sub x {
state $x = 42;
state sub x { print eval '$x', "\n" }
\&x;
}
x()->();
__END__
Output:
Segmentation fault: 11
Because this line in pad.c:S_findpadlex:
1141 const PADLIST * const padlist = CvPADLIST(cv);
is trying to read this SV:
SV = UNKNOWN(0x76) (0xaa170e4fd) at 0x10060c928
REFCNT = 1697135711
FLAGS = (PADSTALE,TEMP,GMG,SMG,IOK,pNOK,pPOK,UTF8)
(i.e., gibberish).
During compilation, ‘sub x{’ creates a new CV. When the sub is about
to be installed (when the final ‘}’ is reached), the existing stub
must be reused. So everything is copied from the new CV (PL_compcv)
to the stub. Also, any CvOUTSIDE pointers of nested subs get updated
to point to the erstwhile stub.
State subs were not getting their CvOUTSIDE pointers updated. This
patch implements that.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When freeing a sub, we can’t assume an entry named "&" contains a CV.
It may instead be a weak reference to a format or named sub, or undef
if such a reference went stale, in which case we don’t want to mess
with CvOUTSIDE pointers.
This bug probably goes back to v5.17.1-213-ge09ac07, when weak refer-
ences started being stored in "&" pad entries. It didn’t start trig-
gering AddressSanitizer failures until it was extended to named subs,
in v5.21.6-386-ga70f21d.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes perl #123430.
Single-character entries like "$" and "&" are not actually named
entries, but are partially treated as such for the sake of bookkeeping
and scope. (E.g., a flipflop target must have the same lifetime as a
state variable.)
PadlistMAXNAMED is an optimisation that marks the offset of the high-
est pad slot with a name. If there any many anonymous pad slots after
the last named one, we don’t want to search through them when looking
up a symbol. So we mark the maximum named slot and skip half the pad
if we are lucky.
Commit v5.21.4-51-g14d9114 caused flipflop targets to be allocated as
variables named "$", causing compilation of some generated code to
slow down. At compile time, the name pad is not extended to the
length of the pad until the end of subroutine compilation. So prior
to 14d9114 flipflop targets would not make the name pad any longer.
Now that flipflop targets expand the name pad, stop setting
PadlistMAXNAMED, so that things are no slower than before.
This is not really the best fix, IMO, because code that is sensitive
to this will slow down dramatically if you tweak it ever so slightly
by adding a ‘my $x’ here or there.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This prints 42 as expected (foo initialises $x and bar reads it
via eval):
use 5.01;
sub foo {
state $x = 42;
sub bar {
eval 'print $x // "u", "\n"';
}
}
foo();
bar();
If you predeclare foo and vivify its glob,
use 5.01;
*foo; # vivifies the glob at compile time
sub foo;
sub foo {
state $x = 42;
sub bar {
eval 'print $x // "u", "\n"';
}
}
foo();
bar();
then the output is ‘u’, because $x is now undefined.
What’s happening is that ‘eval’ follows CvOUTSIDE pointers (each sub
points to its outer sub), searching each pad to find a lexical $x. In
the former case it succeeds. In the latter, bar’s CvOUTSIDE pointer
is pointing to the wrong thing, so the search fails and $x is treated
as global. You can see it’s global with this example, which prints
‘globular’:
use 5.01;
*foo; # vivifies the glob at compile time
sub foo;
sub foo {
state $x = 42;
sub bar {
eval 'print $x // "u", "\n"';
}
}
foo();
$main::x = "globular";
bar();
When a sub is compiled, a new CV is created at the outset and put in
PL_compcv. When the sub finishes compiling, the CV in PL_compcv is
installed in the sub’s typeglob (or as a subref in the stash if pos-
sible). If there is already a stub in a typeglob, since that stub
could be referenced elsewhere, we have to reuse that stub and transfer
the contents of PL_compcv to that stub.
If we have any subs inside it, those will now have CvOUTSIDE point-
ers pointing to the old PL_compcv that has been eviscerated. So
we go through the pad and fix up the outside pointers for any subs
found there.
Named subs don’t get stored in the pad like that, so the CvOUTSIDE
fix-up never happens. Hence the bug above.
The bug does not occur if the glob is not vivified before the sub def-
inition, because a stub declaration will skip creating a real CV if it
can. It can’t if there is a typeglob.
The solution, of course, is to store named subs in the outer sub’s
pad. We can skip this if the outer ‘sub’ is an eval or the main pro-
gram. These two types of CVs obviously don’t reuse existing stubs,
since they never get installed in the symbol table. Since named subs
have strong outside pointers, we have to store weak refs in the pad,
just as we do for formats.
|
| |
|
|
|
|
|
|
|
| |
to match the existing convention (OpREFCNT, OpSLAB).
Dave Mitchell asked me to wait until after his multideref work
was merged.
Unfortunately, there are now CPAN modules using OP_SIBLING.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 8771da69db30134352181c38401c7e50753a7ee8.
Pad lists need to carry IDs around with them, so that when something
tries to close over a pad, it is possible to confirm that the right
pad is being closed over (either the original outer pad, or a clone of
it). (See the commit message of db4cf31d1, in which commit I added an
ID to the padlist struct.)
In 8771da69 I found that I could use the memory address of the pad’s
name list (name lists are shared) and avoid the extra field.
Some time after 8771da69 I realised that a pad list could be freed,
and the same address reused for another pad list, so using a memory
address may not be so wise. I thought it highly unlikely, though, and
put it on the back burner.
I have just run into that. t/comp/form_scope.t is now failing
for me with test 13, added by db4cf31d1. It bisects to 3d6de2cd1
(PERL_PADNAME_MINIMAL), but that’s a red herring. Trivial changes
to the script make the problem go away. And it only happens on non-
debugging builds, and only on my machine. Stepping through with gdb
shows that the format-cloning is following the format prototype’s out-
side pointer and confirming that it is has the correct pad (yes, the
memory addresses are the same), which I know it doesn’t, because I can
see what the test is doing.
While generation numbers can still fall afoul of the same problem, it
is much less likely.
Anyway, the worst thing about 8771da69 is the typo in the first word
of the commit message.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
distinct from SV. This should fix the CPAN modules that were failing
when the PadnameLVALUE flag was added, because it shared the same
bit as SVs_OBJECT and pad names were going through code paths not
designed to handle pad names.
Unfortunately, it will probably break other CPAN modules, but I think
this change is for the better, as it makes both pad names and SVs sim-
pler and makes pad names take less memory.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We already have the name SVs available, not just the string and length.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Another ‘variable’ warning about lexical subs that I missed.
|
| |
|
|
| |
This is more efficient than creating a temporary SV.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to 5.16, pad names never used the UTF8 flag, and all non-ASCII
pad names were in UTF8. Because the latter was consistently true,
everything just worked anyway.
In 5.16, UTF8 handling was done ‘properly’, so that non-ASCII UTF8
strings were always accompanied by the UTF8 flag.
Now, it is still the case that the only non-ASCII names to make their
way into pad name code are in UTF8. Since ASCII is a subset of UTF8,
we effectively *always* have UTF8 pad names. So the flag handling is
actually redundant.
If we just assume that all pad names are UTF8 (which is true), then
we don’t need to bother with the flag checking. There is actually
no reason why we should have two different encodings for storing
pad names.
So this commit enforces what has always been the case and removes the
extra code for converting between Latin-1 and UTF8. Nothing on CPAN
is using the UTF8 flag with pads, so nothing should break. In fact,
we never documented padadd_UTF8_NAME.
|
| |
|
|
|
|
|
|
| |
This was added by 6de654a5, and the assert that makes sure the
reference count is exactly 1 was added in the same commit. After
several years, I think we can be sure now that the reference count
is indeed always 1. We don’t need to ‘play it safe’ for non-debug-
ging builds.
|
| |
|
|
| |
This is in preparation for making PADNAME a separate type.
|
| |
|
|
|
|
| |
When encoding.pm affects variable names, it decodes them to UTF-8, and
when it doesn’t non-ASCII lexical variable names are prohibited. So
this code is not necessary.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is in preparation for making PADNAME a separate type.
This commit is not perfect. What I did was temporarily make PADNAME a
separate struct identical to struct sv and make whatever changes were
necessary to avoid compiler warnings. In some cases I had to add tem-
porary SV casts.
|
| |
|
|
| |
In particular, remove all instances of 'assert(0);'.
|
| |
|
|
|
| |
UTF8 lexical sub names were getting mangled, with extra junk on the end,
due to a precedence problem.
|
