| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SvPVX slot of a CV is used both for the prototype and for the sub
name passed to an XS AUTOLOAD sub.
It used to be that such AUTOLOADing would clobber the prototype.
Commit 8fa6a4095 made the two uses of SvPVX try to play along nicely
with each other, so the prototype comes after the sub name if both
need to be present. It added the CvPROTO macro to account for that.
Some CPAN modules expect to be able to set the prototype with
sv_set[ps]v. So this commit makes that work as expected, by turn-
ing off the flag that says the prototype comes after the auto-
loaded sub name.
Anyone using Scalar::Util::set_prototype to work around the proto-
type-clobbering bug can now continue to do so, without triggering
a new bug.
|
| |
|
|
|
|
| |
I meant to call this mro ‘just @ISA’, because it just uses @ISA and
no super-superclasses. But I misnamed it. It has nothing to do
with @INC.
|
| |
|
|
|
|
|
|
|
|
| |
Perl has assumed up till now that the first element of an isa linear-
isation is the name of the class itself. That is true for dfs and c3,
but not requiring that makes it easier for plugin authors.
Since various parts of the mro code make that assumption, this commit
copies the AV returned by mro_alg.resolve to a new one beginning with
the class’s own name, if the original AV did not include it.
|
| |
|
|
|
|
|
|
|
|
| |
The SvPVX field of a XS AUTOLOAD sub can contain both the prototype
and the name of an AUTOLOADed sub. The CvPROTO macro knows where in
the buffer to find the prototype. All code that reads the prototype
should use it. When I introduced it with commit 8fa6a4095, one code
path was missed: *regular_prototyped_sub = \&prototyped_XS_AUTOLOAD
was using the sub name of the rhs, instead of the prototype, in the
prototype check.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Did you know that a subroutine’s prototype can be modified with s///?
Don’t look:
*AUTOLOAD = *Internals'SvREFCNT;
my $f = "Just another "; eval{main->$f};
print prototype AUTOLOAD;
$f =~ s/Just another /Perl hacker,\n/;
print prototype AUTOLOAD;
You did look, didn’t you? You must admit that’s creepy.
The problem goes back to this:
commit adb5a9ae91a0bed93d396bb0abda99831f9e2e6f
Author: Doug MacEachern <dougm@covalent.net>
Date: Sat Jan 6 01:30:05 2001 -0800
[patch] xsub AUTOLOAD fix/optimization
Message-ID: <Pine.LNX.4.10.10101060924280.24460-100000@mojo.covalent.net>
Allow AUTOLOAD to be an xsub and allow such xsubs
to avoid use of $AUTOLOAD.
p4raw-id: //depot/perl@8362
which includes this:
+ if (CvXSUB(cv)) {
+ /* rather than lookup/init $AUTOLOAD here
+ * only to have the XSUB do another lookup for $AUTOLOAD
+ * and split that value on the last '::',
+ * pass along the same data via some unused fields in the CV
+ */
+ CvSTASH(cv) = stash;
+ SvPVX(cv) = (char *)name; /* cast to loose constness warning */
+ SvCUR(cv) = len;
+ return gv;
+ }
That ‘unused’ field is not unused. It’s where the prototype is
stored. So, not only is it clobbering the prototype, it’s also leak-
ing it by assigning over the top of SvPVX. Furthermore, it’s blindly
assigning someone else’s string, which could be freed before it’s
even used.
Since it has been documented for a long time that SvPVX contains the
name of the AUTOLOADed sub, and since the use of SvPVX for prototypes
is documented nowhere, we have to preserve the former.
So this commit makes the prototype and the sub name share the same
buffer, in a manner resembling that which CvFILE used before I changed
it with bad4ae38.
There are two new internal macros, CvPROTO and CvPROTOLEN for retriev-
ing the prototype.
|
| | |
|
| | |
|
| |
|
|
|
| |
This adds _pv, _pvn, and _pv versions of whichsig() in mg.c, which
get both kill "NAME" and %SIG lookup nul-clean.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commit introduced some code that concatenates a pv on to
an sv and then does SvUTF8_on on the sv if the pv was utf8.
That can’t work if the sv was in Latin-1 (or single-byte) encoding
and contained extra-ASCII characters. Nor can it work if bytes are
appended to a utf8 sv. Both produce mangled utf8.
There is apparently no function apart from sv_catsv that handle
this. So I’ve modified sv_catpvn_flags to handle this if passed the
SV_CATUTF8 (concatenating a utf8 pv) or SV_CATBYTES (cancatenating a
byte pv) flag.
This avoids the overhead of creating a new sv (in fact, sv_catsv
even copies its rhs in some cases, so that would mean creating two
new svs). It might even be worthwhile to redefine sv_catsv in terms
of this....
|
| | |
|
| |
|
|
| |
As with the previous commit, no Perl-level visible changes.
|
| |
|
|
|
|
|
| |
Since gv_fetchmeth_pvn is primarily used from within gv.c,
and not much of anything is passing in the flag yet, this has
no visible changes on the Perl level; So tests remain
entirely in XS::APItest for the time being.
|
| |
|
|
| |
This also uncomments the UTF-8 tests in XS::APItest.
|
| |
|
|
|
|
|
|
| |
newXS was merged into newXS_flags; added a line in the docs
recommeding using that instead.
newCONSTSUB got a _flags version, which generates the CV in
the right glob if passed the UTF-8 flag.
|
| |
|
|
|
| |
Since multi is a boolean (even though it’s typed as an int), there is
no need to have a separate parameter. We can just use a flag bit.
|
| |
|
|
|
|
|
|
|
| |
Now that a glob can be initialized and fetched in UTF-8,
the next commit will introduce some changes in toke.c to
actually test this.
Committer’s note: To keep tests passing I had to incorporate
the toke.c:S_pending_ident changes in the same patch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
passed the UTF8 flag.
newCONSTSUB is still unclean however, so constant subs are
still generated under a wrong name.
gv_fullname4 is also UTF-8 aware now; While that should've gotten
it's own commit and tests, it's not possible to test the
UTF-8 part without the gv_init changes, and it's not possible
to test the gv_init changes without gv_fullname4.
Chicken and egg, as it were. So let's compromise and
wait for the relevant tests once globs can be intiialized as
UTF-8 from the Perl level without XS magic.
|
| |
|
|
|
|
|
|
| |
method is a boolean flag (typed I32, but used as a boolean) added by
commit 54310121b442.
These new gv_autoload_* functions have a flags parameter, so there’s
no reason for this extra effective bool. We can just use a flag bit.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The 4 was added in commit 54310121b442 (inseparable changes during
5.003/4 developement), presumably the ‘Don't look up &AUTOLOAD in @ISA
when calling plain function’ part.
Before that, gv_autoload had three arguments, so the 4 indicated the
new version (with the method argument).
Since these new functions don’t all have four arguments, and since
they have a new naming convention, there is not reason for the 4.
|
| | |
|
| |
|
|
|
|
| |
In addition from taking a flags parameter, it also takes the
length of the method; This will eventually make method
lookup nul-clean.
|
| |
|
|
| |
It was not doing the sanity check for all three functions.
|
| | |
|
| |
|
|
|
| |
It wasn’t doing the XS::APItest::gv_fetchmeth_type sanity check for
all three gv_fetchmeth* functions.
|
| |
|
|
|
| |
I'm probably pushing this too early. Can't do the
Perl-level tests because of that. TODO.
|
| |
|
|
|
|
|
|
|
| |
gv_init_pvn() is the same as the old gv_init(), but takes
a flags parameter, which will be used for the UTF-8 cleanup.
The old gv_init() is now implemeneted as a macro in gv.h.
Also included is some minimal testing in XS::APItest.
|
| |
|
|
|
| |
This new script tests that goto &xsub causes the sub to see the hints,
not of the subroutine it replaces, but of that subroutine’s caller.
|
| |
|
|
|
|
| |
These are used in other compilation units. The declarations there
use the XS_EXTERNAL macro to indicate an non-static XSUB that is
taken from another object file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 3c78429c102e0fe2ad30c60dfe52636b6071ef19 reduced the depth
of recursion in rpeep(), by deferring recursion into branches until a bit
later (so that the recursive call to rpeep was then likely to be shallow).
However, it went one step further: when the chain of op_next's had been
exhausted in the main loop, it processed any remaining deferrred branches
in the main loop rather than recursing. All nice and efficient, but it
broke the expectation that someone who had hooked into rpeep could follow
the chain of op_nexts in each call and visit *all* ops.
This commit removes that optimisation and restores the rpeep hook
expectancy. This shouldn't have any major effect on the depth of
recursion, and its minor inefficiency doesn't really matter for a
one-time compilation-time pass.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
8375c93eec supplied tests for a newly exported API but the type
declarations for the arguments and return values didn't match the
types of the API being tested.
aebc0cbee0 renamed the functions without updating the calls to
those functions in the test.
Either of these could have been easily spotted by building with
g++ (or other readily available tools) before pushing.
This aside from the controversy over whether this particular API
is the one that should be publicly exported, so this all may be
reverted and replaced before 5.16.0, but hopefully it will unbreak
the build for now.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Long blocks of code that include logical or loop ops (i.e. those with
multiple 'branches' of ops, such as op_other, op_redo etc) cause
Perl_rpeep to recurse deeply and eventaully SEGV.
For example this crashes, due to the ENTERLOOP:
eval ("{\$x = 1 }\n" x 10000)
The deep recursion happens because the processing of the entire rest of
the code occurs in within the nested call. For example in the code
A && B; C; D; E;
the ops are structured as
A -> AND -> C -> D -> E
\ /
B
where AND->op_next points to C, while AND->op_other points to B.
rpeep() would normally process each op in the op_next sequence in turn
(i.e. A/AND/C/D/E), but when it reaches AND, it recursively calls
rpeep(B), which happens to then process B/C/D/E. Finally it returns,
and the parent rpeep processes C, finds it's already done, and exits.
Clearly, if C,D,E etc also contain conditional/loop ops, then the
recursion level gradually stacks up.
The fix for this is to add a small deferred queue to rpeep().
Whenever rpeep wants to recurse with op_other or op_lastop etc,
it instead adds it to the deferred queue. Only if the queue is full is
rpeep actually called. The hope is that by deferring, when we do
eventually process it, enough of the main op_next chain has already been
processed to ensure that the child rpeep returns very early.
In the example above, processing of AND causes B to be added to the queue,
and the main rpeep process continues processing C, D etc. Sometime later,
the queue becomes full and B is processed via a recursive call to rpeep.
B is processed, and op_next is followed to C, but C is marked as already
processed, so the child rpeep returns almost immediately.
For LOOP ops, I've stopped following op_redoop and op_nextop, since
AFAIKT the ops these point to will also be reachable vie op_next anyway.
op_lastop is the exception; in while(1){..} only op_lastop points to the
rest of the code block.
Note that this commit doesn't guarantee only shallow recursion, it just
makes deep recursion fairly unlikely.
Note also that this commit causes the order of the processing of op_next
chains to be altered; this can affect the ordering of compiler warnings
and fatal messages among potentially other things.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Move several pad functions into the core API. Document the pad
functions more consistently for perlapi. Fix the interface issues
around delimitation of lexical variable names, providing _pvn, _pvs,
_pv, and _sv forms of pad_add_name and pad_findmy.
|
