| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This only affected threaded builds. I think the comments in the added
test explain well enough what was happening.
The solution is to store a stashpad offset in the pmop, instead of the
name of the stash. This is similar to what was done with cop stashes
in d4d03940c58a.
Not only does this fix the crash, but it also makes compilation faster
and saves memory (no separate malloc for every m?pat?).
I had to move Safefree(PL_stashpad) later on in perl_destruct, because
freeing a pmop causes the PL_stashpad to be accessed, and pmops can be
freed during sv_clean_all. Its previous location was not a problem
for cops, as PL_stashpad[cop->cop_stashoff] is only accessed when
PL_curcop==that_cop and Perl code is running, not when cops are freed.
|
| |
|
|
|
|
|
|
|
| |
According to the documentation, reset() with no argument resets pat-
terns. But reset "" and reset "\0foo" were also resetting patterns.
While I was at it, I fixed embedded nulls, too, though it’s not likely
anyone is using this. I could not fix the bug within the existing API
for sv_reset, so I created a new function and left the old one with
the old behaviour. Call me pear-annoyed.
|
| |
|
|
|
|
|
| |
Because sometimes the "it can never happen" does. For example, "panic: free
from wrong pool". And it's awfully confusing if the error message is eaten.
There's not even a "I barfed you an error but then I eated it" caption to give
a clue about what happened.
|
| |
|
|
|
|
|
|
|
|
| |
Deprecate ?PATTERN?, recommending the equivalent m?PATTERN? syntax, in
order to eventually allow the question mark to be used in new operators
that would currently be ambiguous.
(With minor reconciliation edits by David Golden)
Signed-off-by: David Golden <dagolden@cpan.org>
|
| |
|
|
|
| |
deleting pattern match ops in another thread.
p4raw-id: //depot/perl@30856
|
| |
|
|
|
| |
combination.
p4raw-id: //depot/perl@30845
|
|
|
p4raw-id: //depot/perl@30844
|
