| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ perl5.17.2 -Mblib -e 'sub foo{}; foo $bar; use Lexical::Sub baz => sub{}; baz $bar'
Can't call method "baz" on an undefined value at -e line 1.
$ perl5.17.2 -Mblib -e 'sub foo{}; foo bar; use Lexical::Sub baz => sub{}; baz bar'
Can't locate object method "baz" via package "bar" (perhaps you forgot to load "bar"?) at -e line 1.
So if you use Lexical::Sub, your sub doesn’t get to participate in
determining whether ‘foo $bar’ or ‘foo bar’ is a method call.
This is because Lexical::Sub uses an rv2cv hook to intercept sub
lookup. And toke.c:S_intuit_method thinks there cannot be a CV with-
out a GV (which was the case when it was first written).
Commit f7461760 introduced this rv2cv hooking for bareword lookup, but
failed to update S_intuit_method accordingly.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an op is allocated, PL_compcv is checked to see whether it can
hold an op slab if it does not hold one already. If PL_compcv is not
usable, for whatever reason, it falls back to malloc.
Since the new slab allocator was added in commit 8be227a, newFOROP has
been assuming, probably correctly, that its listop which it needs to
enlarge to a loopop was allocated by slab.
Since newFOROP is an API function, we should err on the safe side and
check first whether the op is slab-allocated, falling back to realloc
if it is not.
To trigger this potential bug, one has to set things up such that
there is a usable pad available, but no usable PL_compcv. I said
‘probably correctly’ above because this situation is highly unlikely
and probably indicative of bugs elsewhere. (But we should still err
on the side of safety.)
|
| |
|
|
|
|
|
|
|
|
| |
These macros have never worked outside the Latin1 range, so this extends
them to work.
There are no tests I could find for things in handy.h, except that many
of them are called all over the place during the normal course of
events. This commit adds a new file for such testing, containing for
now only with a few tests for the isBLANK's
|
| |
|
|
|
|
|
|
|
| |
The XS API allows hash entries to be created with null values. perl
itself uses these internally, too.
Though they should rarely be seen by Perl code, Perl ops should still
be able to handle them without crashing (by croaking). I fixed helem
and hslice in 5.16 (commit 746f6409), but missed localised deletions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I ran into a bit of a problem when building perl-5.16.0.
'make test' showed a segfault in ext/XS-APItest/t/clone-with-stack.t.
It seems to be caused by accessing already freed memory, it
segfaults because I have MALLOC_PERTUBE_ set, thus glibc fills
freed memory with some value.
Digging deeper, it seems like perl_clone() does not fix
the cx's blk_oldcop element when doing context cloning, thus
blk_oldcop still points to PL_compiling in the old interp--the
calling scope for the BEGIN block being the compilation of the
code surrounding it--and the POPBLOCK done in leavesub will copy
the data from the old interp to PL_curcop.
After fixing this, it still crashed because interp_dup->Iop was
zero after the runops_standard() call (which is probably
correct as the end of the BEGIN block was reached). So I
also added an if statement that checks the pointer.
|
| | |
|
| |
|
|
|
| |
This updates the editor hints in our files for Emacs and vim to request
that tabs be inserted as spaces.
|
| |
|
|
|
|
|
|
|
| |
How ironic! Overloading is called ‘A’ magic internally all over the
place, because of the letter used as its magic type. But now it does
not even use that magic.
I left a comment in mg_vtable.pl, so that future maintainers will have
some clue as to what AMAGIC means.
|
| |
|
|
|
| |
Otherwise cv_set_call_checker has no effect inside an attribute han-
dler for a closure.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Magic attached to hash elements has its key stored differently depend-
ing on how it was supplied to hv_common. hv_store passes a string/
length pair to hv_common, while hv_store_ent passes an SV.
magic_clearhint wasn’t able to handle string/length pairs, and only
worked with SVs, resulting in assertion failures or crashes.
This commit fixes magic_clearhint, so that XS code can use hv_store on
hint hashes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
All code points whose UTF-8 representations start with a byte containing
either \xFE or \xFF are considered problematic because they are not
portable. There are many such code points that are too large to
represent on a 32 or even a 64 bit platform. Commit
eb83ed87110e41de6a4cd4463f75df60798a9243 failed to properly catch
overflow when the input flags to this function say to warn on, but
otherwise accept FE and FF sequences. Now overflow is checked for
unconditionally.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The prior version had a number of issues, some of which have been taken
care of in previous commits.
The goal when presented with malformed input is to consume as few bytes
as possible, so as to position the input for the next try to the first
possible byte that could be the beginning of a character. We don't want
to consume too few bytes, so that the next call has us thinking that
what is the middle of a character is really the beginning; nor do we
want to consume too many, so as to skip valid input characters. (This
is forbidden by the Unicode standard because of security
considerations.) The previous code could do both of these under various
circumstances.
In some cases it took as a given that the first byte in a character is
correct, and skipped looking at the rest of the bytes in the sequence.
This is wrong when just that first byte is garbled. We have to look at
all bytes in the expected sequence to make sure it hasn't been
prematurely terminated from what we were led to expect by that first
byte.
Likewise when we get an overflow: we have to keep looking at each byte
in the sequence. It may be that the initial byte was garbled, so that
it appeared that there was going to be overflow, but in reality, the
input was supposed to be a shorter sequence that doesn't overflow. We
want to have an error on that shorter sequence, and advance the pointer
to just beyond it, which is the first position where a valid character
could start.
This fixes a long-standing TODO from an externally supplied utf8 decode
test suite.
And, the old algorithm for finding overflow failed to detect it on some
inputs. This was spotted by Hugo van der Sanden, who suggested the new
algorithm that this commit uses, and which should work in all instances.
For example, on a 32-bit machine, any string beginning with "\xFE" and
having the next byte be either "\x86" or \x87 overflows, but this was
missed by the old algorithm.
Another bug was that the code was careless about what happens when a
malformation occurs that the input flags allow. For example, a sequence
should not start with a continuation byte. If that malformation is
allowed, the code pretended it is a start byte and extracts the "length"
of the sequence from it. But pretending it is a start byte is not the
same thing as it actually being a start byte, and so there is no
extractable length in it, so the number that this code thought was
"length" was bogus.
Yet another bug fixed is that if only the warning subcategories of the
utf8 category were turned on, and not the entire utf8 category itself,
warnings were not raised that should have been.
And yet another change is that given malformed input with warnings
turned off, this function used to return whatever it had computed so
far, which is incomplete or erroneous garbage. This commit changes to
return the REPLACEMENT CHARACTER instead.
Thanks to Hugo van der Sanden for reviewing and finding problems with an
earlier version of these commits
|
| | |
|
| |
|
|
|
| |
This meant changing LABEL's definition in perly.y, so most of this
commit is actually from the regened files.
|
| |
|
|
|
| |
These functions should be used in preference to the old ones which can
read beyond the end of the input string.
|
| |
|
|
|
| |
This function provides a convenient and thread-safe way for modules to
hook op checking.
|
| |
|
|
|
|
| |
It was setting this even on magical variables, causing stringification
not to bother calling FETCH, because the POK flag means ‘yes, I’m a
bonified [sic] string, with nothing funny going on’.
|
| | |
|
| |
|
|
|
| |
Instead of just doing SvPV on something that is not a PV, SvPVbyte
should actually do what it is advertised as doing.
|
| |
|
|
| |
It didn’t until the previous commit.
|
| |
|
|
|
|
|
|
|
|
| |
In shouldn’t destroy globs or references passed to it, or try to
coerce them if they are read-only or incoercible.
I added tests for SvPVbyte at the same time, even though it was not
exhibiting the same problems, as sv_utf8_downgrade doesn’t try to
coerce anything. (SvPVbyte has its own set of bugs, which I hope to
fix in fifthcoming commits.)
|
| |
|
|
| |
so it can be changed without one having to search for it.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It’s possible for XS code to create hash entries with null values.
pp_helem and pp_slice were not taking that into account. In fact,
the core produces such hash entries, but they are rarely visible from
Perl. It’s good to check for them anyway.
|
| | |
|
| |
|
|
| |
without touching anything else.
|
| |
|
|
|
|
|
| |
This reverts commit d54b00ad7f0e9db12ac11e897406b8888fd895bf.
I didn’t mean to push that yet, and it was more than a
version bump.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no reason why constant redefinition warnings should be
default warnings for sub foo(){1}, but not for newCONSTSUB (which
calls newXS, which triggers the warning).
To make this work properly, I also had to import sv.c’s ‘are these
const subs from the same SV originally?’ logic. Constants created
with XS can have NULL for the SV (they return an empty list or
&PL_sv_undef), which means sv.c’s logic will stop *this=\&that from
warning if both this and that are such XS-created constants.
newCONSTSUB needed to be consistent with that. It required tweaking a
test I added a few commits ago, which arguably shouldn’t have warned
the way it was written.
As of this commit (and before it, too, come to think of it),
newXS_len_flags’s calling convention is quite awful and would need to
be throughly re-thunk before being made into an API, or probably sim-
ply never made into an API.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
newCONSTSUB uses the compile-time warning hints, instead of the run-
time hints. This means that
use warnings;
BEGIN {
no warnings;
some_XS_function_that_calls_new_CONSTSUB();
}
may trigger a redefinition warning, whereas it should be analogous to
use warnings;
BEGIN {
no warnings;
*foo = \&bar;
}
which does not warn.
newCONSTSUB localises PL_curcop and sets it to &PL_compiling. When it
does that, it needs to copy the hints over.
Running tests inside eval is not reliable without a test count, so I
added one.
|
| | |
|
| |
|
|
|
|
|
|
| |
This reverts commit 01394286a8355f7c2b1de8f793a62c37d4aa265e.
I made the mistake (again!) of merging two unrelated commits.
I’m reverting it so that the B::Deparse change can include a
helpful commit message.
|
| | |
|
| |
|
|
|
| |
This function was added after 5.14.0, so it is not too late to
change it. It is currently unused.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Usually when a BEGIN block exits it has to set PL_curcop to
&PL_compiling, so that subsequent compiled code in the surrounding
scope will have the right warning hints during compilation.
If an XS function creates a BEGIN block via newXS or newATTRSUB, how-
ever, the assumption that compilation will resume as soon as the block
exits is false.
This can be demonstrated with this code, which warns about CHECK and
INIT blocks created too late when it shouldn’t due to ‘no warnings’:
use warnings;
eval q|
BEGIN{
no warnings;
package XS::APItest; require XSLoader; XSLoader::load()
}
|;
In every case where it is correct for BEGIN to set PL_curcop to
&PL_compiling when it exits it is actually just restoring it to its
previous value, so localisation is the right fix.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
When a filter is added, the current buffer is hung on the end of
the filters array, and a new substring of it becomes the current
buffer.
|
| |
|
|
|
|
| |
Source filters have always been byte-level filters. Therefore they
don’t make sense on Unicode strings, unless we are planning to add
new APIs to support it. Until then, croak.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These stopped working when the CvROOT and CvXSUB fields were merged
in 5.10.0:
$ perl5.8.9 -le 'print sort utf8::is_utf8 2,1'
Usage: utf8::is_utf8(sv) at -e line 1.
$ perl5.10.0 -le 'print sort utf8::is_utf8 2,1'
12
(In the latter case, the utf8::is_utf8 routine is not being called.)
pp_sort has this:
if (!(cv && CvROOT(cv))) {
if (cv && CvISXSUB(cv)) {
But CvROOT is the same as CvXSUB, so that block is never entered for
XSUBs, so this piece of code later on:
if (is_xsub)
PL_sortcop = (OP*)cv;
else
PL_sortcop = CvSTART(cv);
sets PL_sortcop to CvSTART for XSUBs, but CvSTART is NULL. Later on,
this if condition fails:
if (PL_sortcop) {
so the XSUB is treated as being absent.
|
| |
|
|
|
|
| |
I added it to an existing block without realising that it was for
a separate package and that the standard convention throughout
APItest.xs is to use a separate BOOT block for every tested feature.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 5.6.0, XS autoloading worked. $AUTOLOAD would be set, as with
a Perl sub.
Commit ed850460 (5.6.1) allowed ‘sub AUTOLOAD;’ to prevent autoload
inheritance. But the code to check for that mistakenly equated an
XSUB with a forward declaration. So XS autoloading simply did not
work any more.
Then someone found it didn’t work and introduced it as a ‘new’ feature
in 5.8.0, with commit adb5a9ae. For efficiency’s sake, instead of
joining the package name and sub name together, only to have the XSUB
do the same, it set the CvSTASH and SvPVX fields of the SV.
SvPVX was already being used for the sub’s prototype, so 8fa6a409
(just recently) made the autoloaded sub name and the prototype play
along nicely together, with a few fix-up commits (05b525f4, 3d5f9785
and 74ee33f2).
It was only after that that I find out that $AUTOLOAD used to be set
for XSUBs. See the discussion at these two links
http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=4E9468E8.8050206@cpan.org
https://rt.perl.org/rt3/Ticket/Display.html?id=72708
This commit restores the original behaviour of setting $AUTOLOAD for
XSUBs, while retaining the CvSTASH+SvPVX method as well, as it has
been documented for a while.
Steffen Müller’s AUTOLOAD tests that I committed recently (120b7a08)
needed to be adjusted a bit. The test count was off, which was my
fault (I *thought* I had checked that.) The test XSUB was using
get_sv("AUTOLOAD"), which ended up fetching the caller’s $AUTOLOAD.
It was also using SvPV_set on an undefined scalar, which does not turn
the SvPOK flag on.
|
| |
|
|
|
|
|
|
|
|
| |
If an AUTOLOAD sub is an XSUB, $AUTOLOAD won't be set. This is intended
as an optimization, but $AUTOLOAD *was* set back in 5.6.0, so this is
a regression.
Committer’s note: I modified the commit message and the comments, as
the original author did not know about the autoload mechanism setting
CvSTASH. For that matter, neither did I till yesterday.
|
