HvNAME_HEK((HV*)CopSTASH(cx->blk_oldcop)) does some implicit assumptions, which should
better be asserted. Also record CX pp_caller reads besides PUSH and POP.
Perl_sv_compile_2op_is_broken() does at line 3354 a LEAVE_with_name("eval"),
a SSPOPSTR via SAVEt_SHARED_PVREF for the localized cop_stashpv, but
not for the cop_stashlen.
The cop in question is PL_compiling, which was "AutoSplit" before with
len=9 and restores it back to "main" but keeps len 9. Thus leading to a
heap-overflow in gv_stashpvn.
Until now, only overridable keywords had subs in the CORE:: namespace.
This branch adds subs to the CORE:: namespace for those non-overrida-
ble keywords that can be implemented without custom parsers.
Unless called as &CORE::undef (without parentheses) after @_ has been
set to \*_, it leaves @_ in the ARRAY slot.
This is an implementation detail leaking through.
pp_entersub temporarily aliases @_ to a new array, which is restored
to its previous value on sub exit.
Since &CORE::undef is a perl sub with an op tree containing
an undef op,
$ ./perl -Ilib -MO=Concise,CORE::undef -e '\&CORE::undef'
CORE::undef:
3 <1> leavesublv[1 ref] K/REFC,1 ->(end)
2 <1> undef sKP/1 ->3
1 <$> coreargs(IV 44) s ->2
-e syntax OK
the undef op runs while @_ is localised.
So we should un-localise @_ if we detect that case.
Doing this in pp_coreargs might be a bit of a hack, but it’s less
code than rewriting &CORE::undef as an XSUB, which would be the
other option.
Either way, we need a special case, since undef is the only named op
that touches the ARRAY slot of the glob passed to it.
In the error message, we can’t say ‘&CORE::undef operator’, so we
should be using the op name, rather than the op description.
Instead of using OP_NAME(PL_op->op_next), which would expand to
PL_op->op_next->op_type == OP_CUSTOM
? XopENTRY(Perl_custom_op_xop(aTHX_ PL_op->op_next), xop_name)
: PL_op_name[PL_op->op_next->op_type]
we can simply use PL_op_name[opnum], which should be quicker.
pp_undef can already handle nulls on the stack.
There is one remaining problem. If &CORE::undef(\*_) is called, *_
will be undefined while @_ is localised during the sub call, so it
won’t have the same effect as undef *_. I don’t know whether this
should be considered a bug or not, but I could solve it by making
pp_undef an XSUB.
In regen/opcodes, we have some operators that use ck_fun and have R
for the argument. And there are some that use ck_lfun and have S for
the argument.
These both amount to more or less the same thing.
ck_fun/R goes through the OA_SCALARREF case in ck_fun, which calls
op_lvalue(scalar()) on the child op.
ck_lfun/S goes through the OA_SCALAR case in ck_fun, which calls
scalar(), and then ck_lfun sees to it that op_lvalue is called.
The only real difference is that the OA_SCALAR case makes sure there
are not too many arguments.
Since both core_prototype and pp_coreargs need special cases to deal
with OA_SCALAR that is really ‘supposed’ to be OA_SCALARREF, it
becomes simpler to add &CORE::undef if undef uses R. In that case,
we also have to put the argument-checking in the OA_SCALARREF, but we
make it conditional on the op being an undef op, for the sake of doing
one thing at a time. (This is a bit of a mess; see ticket #96006.)
I added a special case for OP_GLOB to pp_coreargs, since glob does not
have the u flag in regen/opcodes; hence PL_opargs[opnum] & OA_DEFGV is
false, even though glob does imply $_.
Adding the flag to regen/opcodes is not so simple, as the code in
ck_fun that adds the DEFSV op does not account for list ops, but
leaves op_last unchanged.
Changing ck_fun to account requires adding more code than this special
case in pp_coreargs.
OPf_SPECIAL indicates that glob was called with the CORE:: prefix.
Instead of using OP_DESC on op_next, since we already know the op
number, we can just go straight to PL_op_desc, which is what OP_DESC
itself uses after looking inside op_next to find out what the op
number is.
BTW, &CORE::scalar will need this, since a scalar op is never actu-
ally executed, making coreargs’ op_next pointer point to another op
than expected:
2 <1> leavesublv[1 ref] K/REFC,1 ->(end)
- <1> scalar sKP/1 ->2
1 <$> coreargs(IV 2) s ->2
-e syntax OK
Otherwise we get ‘Not enough arguments for lvalue subroutine return’.
Instead of skipping positive keywords (those that cannot be over-
ridden) because of their positivity, list them explicitly in the
skip list.
This will allow them to be removed one by one.
Instead of skipping positive keywords (those that cannot be over-
ridden) because of their positivity, list them explicitly in the
skip list.
This will allow them to be removed one by one.
S_maybe_add_coresub returns NULL for any keywords that are not
overridable.
Instead of identifying them by the positivity of their codes, list
them all explicitly.
This will allow coresubs to be added for them one by one.
‘Positive’ means having a + before it in regen/keywords.pl; i.e., key-
words that cannot be overridden.
Since all keywords are going to be added as subs to the CORE:: name-
space, with prototypes wherever they can apply, it makes sense to
return prototypes for all that can have them, which turns out to be
only a handful.
Near the start of link(), $output gets set to a blib\arch\auto path.
A little later that gets copied into $spec{output}, but $spec{manifest}
is left unset so it gets set later to a $spec{builddir} path, which is
not what $spec{output} was set to earlier.
The manifest file is always created alongside the DLL, so the correct
fix is simply to append '.manifest' to the DLL path to find the manifest.
(EU-MM does that too.)
Patch taken from [cpan #35943] which reported the same problem. The other
concern raised there, about the VC version being checked to deduce the
existence of the manifest file rather than testing that directly, has
long since been incorporated already and also explains why this problem
has not been seen recently: the faulty attempt to embed the manifest has
not been attempted ever since the existence test was added because it was
also failing and hence no 'mt' command was being run. [cpan #35943] is
thus resolved by this change too.
Bump $VERSION in all ExtUtils::CBuilder files (to 0.280208) to keep them
all in sync as before.
Correct the test for the existence of the manifest file.
Bump $VERSION in all ExtUtils::CBuilder files (to 0.280207) to keep them
all in sync, as is currently the case.
Before this commit, this:
vec(my $v,0,1) = 1;
would've produced four warnings about uninitialized values;
however, the ticket argued that these were spurious.
This commit removes the warning in the case of lvalue vec, since it is
similar to |=, but leaves it in place for rvalue vec.
Previously, if SV_UNDEF_RETURNS_NULL was passed to sv_pvn_force_flags,
it would call sv_2pv_flags with that flag, and get back a NULL instead
of a char *, which lead to issues.
This commit makes sv_pvn_force_flags use an empty string in that case.
File::Spec::UNIX->abs2rel() returns wrong results in a few cases, most
of which involve ".." path components.
To reproduce, paste the following test cases into:
perl -MFile::Spec::Unix -n -e 'print File::Spec::Unix->abs2rel(split),"\n";'
../foo bar/bat
bar/bat ../foo
foo bar/../bat
. .
/ /
Correct results when run at /home/me and no symlinks in base path:
../../../foo
../me/bar/bat
../foo
.
.
Results for File::Spec::Unix from PathTols 3.33:
../../foo
../bar/bat
../../../foo
/
/
The error in the first test case is due to an optimisation applied when
both arguments are relative paths, which prepends "/" instead of the
current directory. "/../" is then converted to "/" by canonpath().
I have replaced this optimisation by a single call to _cwd() in the
following patch. This also fixes the fourth test case. Besides, I have
moved checks which make sense only for absolute path arguments to the
first branch of the if.
(hunk @@ -366,28 +367,32 @@)
The error in the last test case arises because a root dir $base is
treated specially, and catdir() does not work well for fewer than two
path components. The first added line in the following patch catches that.
As regards the second and third test case, they can be solved without
consulting the filesystem only if no symlinks are involved. Whereever
$path contains .. components, the corresponding directory has to be
descended into. The following patch does this.
(hunk @@ -395,19 +400,39 @@)
It can be impossible for abs2rel() to work correctly without looking at
the filesystem if $base contains symlinks. I understand from the
documentation that the File::Spec modules are not meant to consult the
filesystem. Even though the docs state that abs2rel() does not consult
the filesystem, the implications could perhaps be made clearer, for
example like this:
(hunk @@ -352,9 +352,10 @@)
