Branch: refs/heads/maint-5.36
Home: https://github.com/Perl/perl5
Commit: 087438c31af9a09867cf323916ec25db60089561
https://github.com/Perl/perl5/commit/087438c31af9a09867cf323916ec25db60089561
Author: Hugo van der Sanden <h...@crypt.org>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M sv.c
M t/op/taint.t
Log Message:
-----------
GH19478: applying taint is no reason to mess with pos
25fdce4a16 introduced a chunk in sv_magic() to "force pos to be stored
as characters, not bytes" whenever any magic was applied to a string
marked UTF8.
It is not clear why a random call to sv_magic(), eg to mark a string as
tainted, needs to do this - it would seem more logical for the check to
happen either earlier (when the string first qualifies as SvMAGICAL(sv)
&& DO_UTF8(sv)) or later (eg on mg_find).
Experimentally remove this block - it appears to cause no test failures,
and allows the new test cases to pass.
(cherry picked from commit f757874dac95bb608303f02ed7a2eeeaf1ec116b)
Commit: 3017a3a26efb5701ab447d5df791efbdb20e2772
https://github.com/Perl/perl5/commit/3017a3a26efb5701ab447d5df791efbdb20e2772
Author: David Mitchell <da...@iabyn.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M pp_ctl.c
M t/re/pat_re_eval.t
Log Message:
-----------
fix panic from eval {} inside /(?{...})/
GH #19680
Normally in code like
eval {.... };
then even if the eval is the last statement in the file or sub, the
OP_LEAVETRY isn't the last op in the execution path: it's followed
by an OP_LEAVE or OP_LEAVESUB or whatever, which will be the op to
resume execution from after an exception is caught.
However, if the eval is the *last* thing within a regex code block:
/(?{ ...; eval {....}; })/
then the op_next pointer of the OP_LEAVETRY op is actually NULL.
This confused S_docatch(), which wrongly assumed that a NULL
PL_restartop indicated that the caught exception should be rethrown,
popping execution back to the outer perl_run() call and hence leading to
the confused panic warning:
"panic: restartop in perl_run"
The fix is to to separate out the "do we need to re-throw" test,
(PL_restartjmpenv != PL_top_env), from the "no more ops so no need to
re-enter the runops loop" test, (!PL_restartop).
(cherry picked from commit 5fd637ce8c4db075c0668d9f9c806f6712cd3c7f)
Commit: b58a5021fc2410b365424340062f85b7a09462f7
https://github.com/Perl/perl5/commit/b58a5021fc2410b365424340062f85b7a09462f7
Author: David Mitchell <da...@iabyn.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M pp_ctl.c
M t/re/pat_re_eval.t
Log Message:
-----------
fix another panic from eval {} inside /(?{...})/
GH #19390
This issue is similar to GH #19680 (fixed by v5.37.0-272-g5fd637ce8c),
but exiting the eval via a syntax error rather than via raising an
exception.
In this case, the NULL op_next of the OP_ENTEREVAL was passed to a new
RUNOPS loop, which would normally SEGV (or on debugging builds, warn
"NULL OP IN RUN").
(cherry picked from commit 16e43efd81368f85ada6f2d40658b305d92ba57e)
Commit: 89d80cc9efb3eefc31aa62b32c9e745f8de6412f
https://github.com/Perl/perl5/commit/89d80cc9efb3eefc31aa62b32c9e745f8de6412f
Author: Yves Orton <demer...@gmail.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M regcomp.h
Log Message:
-----------
regcomp.h: deal with 64 bit aligned pointer data in regex program.
We cannot safely store 64 bit aligned data in a regnode structure due
to the implicit 32 bit alignment the base structure forces on the
data. Thanks to Tony Cook for the suggestion on how to cleanly support
variable sized pointers without alignment issues.
I am pretty sure we should not be storing pointers in the regexp program
like this. In most cases where we need an SV attached to a regnode
structure we store it in the 'data' array which part of the regexp
structure, and then store an index to that item in the regnode. This
allows the use of a smaller member for the index instead.
This was identified by running "make test_reonly" under the ubsan build:
./Configure -d -Doptimize=-g -Dusedevel -DDEBUGGING \
-Accflags='-fsanitize=address -fsanitize=undefined \
-ggdb3' -Aldflags='-Wl,--no-as-needed -lasan -lubsan' \
-Dcc=ccache\ gcc -Dld=gcc
(cherry picked from commit 24a3add986669c1f4ad5040b224428bd097b944e)
Commit: b31d5cb756cdd67b4e9b88e1325e1fdbb21ab63a
https://github.com/Perl/perl5/commit/b31d5cb756cdd67b4e9b88e1325e1fdbb21ab63a
Author: Tony Cook <t...@develop-help.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M op.c
M t/op/lexsub.t
Log Message:
-----------
handle intermediate pads not including the name in find_lexical_cv()
In the following each line is the pad for a scope, starting from
the outermost scope.
In non-eval cases a use of a lexical symbol in an inner pad
also adds that name to the pad in the intermediate scope. So for
code like:
my $bar;
sub foo { ... }
sub f { sub g { foo($bar) } }
we might get pads like:
[&foo] [$bar] # defining pad
[&foo] [$bar] # intermediate pad (for f)
[&foo] [$bar] # using pad (for g)
and each inner pad has an index of the same name in the parent
scope. find_lexical_cv() followed that chain of indexes to find
the definition, or at least the prototype, of the lexical sub.
Unfortunately names can only be added to the pad at compile-time,
so for an eval the intermediate scope is closed to further
modifications, and the pad for the intermediate scope doesn't
get an entry for the name, so code like:
my $bar;
sub foo { ... }
sub f { eval 'foo($bar)' }
we get pads like:
[&foo] [$bar] # defining pad
# intermediate pad (f) doesn't have the names
[&foo] [$bar] # eval 'foo($bar)' pad
but find_lexical_cv() assumed that the names would always exist
in the intermediate pads, and failed an assertion.
find_lexical_cv() now falls back to searching for the cv by name
up the chain of nested pads.
This doesn't fix a slightly related problem:
my sub foo { }
BEGIN {
foo(); # Undefined subroutine &foo
}
The fix for that may make find_lexical_cv() unnecessary, but is a
more complex fix.
(cherry picked from commit b0bc598140d48d19b21d667a581c0dfa28a3749a)
Commit: fdbde98f6a16546fa5769cf07f15f0279dfec98d
https://github.com/Perl/perl5/commit/fdbde98f6a16546fa5769cf07f15f0279dfec98d
Author: Tony Cook <t...@develop-help.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M pp_hot.c
Log Message:
-----------
pp_multiconcat: don't set svpv_p to an invalid pointer
When svpv_base == svpv_buf, svpv_p would be set to point before the
buffer, which is undefined.
This appears to be what gcc 13 is complaining about in #20678,
despite that report including what appears to be a completely valid
address, on a line where the value of svpv_p is now within the range
of svpv_buf.
An intermediate approach to this used:
temp = svpv_p;
if (svpv_p++ == svpv_end)
break
but this is also incorrect, since svpv_p would end up as an invalid
pointer, though gcc UBSAN didn't pick that up.
Fixes #20678.
(cherry picked from commit 92ef216deffb274d2e40a3516632fb089187b008)
Commit: 8e8e68e94c29d13f359ede6f79861bf08cd317f0
https://github.com/Perl/perl5/commit/8e8e68e94c29d13f359ede6f79861bf08cd317f0
Author: Tony Cook <t...@develop-help.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M mg.c
M t/io/defout.t
Log Message:
-----------
check the IO object exists when writing to IO magic variables
pp_select() ensures that the GV in PL_defoutgv has an IO object
when it the default output is set, but can't prevent that GV
being cleared afterwards, resulting in a seg fault when the
variable is written.
To prevent this, check PL_defoutgv has an IO object before trying
to write to it.
Fixes #20733
(cherry picked from commit af62106ad344b13fde54d2c0d5e7e0d0bab96054)
Commit: af0c3b8e997025215641acbf0dee596d0bd9d703
https://github.com/Perl/perl5/commit/af0c3b8e997025215641acbf0dee596d0bd9d703
Author: David Mitchell <da...@iabyn.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M pp_ctl.c
M t/op/write.t
Log Message:
-----------
formats: fix splitting on non-spaces
GH #19985
formats have a mode where they can repeatedly split a string to fill
within a fixed text width, splitting on (by default), spaces, newlines
and hyphens.
The splitting code was heavily rewritten by me in
v5.19.5-218-g9b4bdfd44e, but in that patch I introduced a couple of
off-by-one errors when splitting on non-white-space characters (i.e. the
hyphen by default).
It turns out that splitting on a hyphen is completely untested in core,
and further, no one noticed the problems in the wild until this ticket,
8 years later!
The first issue, and the one in the bug report, is that when splitting,
the calculation for how many spaces to pad to the end of the field was
off by one, so:
$v1 = "AB-CDE";
format STDOUT =
[^<<<]~~
$v1
.
write;
gives:
[AB- ]
[CDE ]
but should have given:
[AB- ]
[CDE ]
The second issue was that it was detecting a hyphen one character
further along than the maximum field length and still splitting it there:
as above, but
$v1 = "ABCD-E";
gives:
[ABCD-]
[E ]
but should have given:
[ABCD]
[-E ]
The latter was because the non-space split code was using the same logic
as the split-on-space code, which is allowed to split on a space which
is one character beyond the maximum length.
This commit fixes both issues, and adds some tests.
(cherry picked from commit 5d7d8ffc298134400c054265830d47abb6ee7845)
Commit: 72b5b2cf1f5da64d71a063f91243295929207570
https://github.com/Perl/perl5/commit/72b5b2cf1f5da64d71a063f91243295929207570
Author: Tony Cook <t...@develop-help.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M gv.c
M t/op/method.t
Log Message:
-----------
only negative cache a method lookup if we look at UNIVERSAL
(cherry picked from commit 64d117434d554b7227e13abbc3ba99ff266b8484)
Commit: 1221515648ebefa1a60a956275f62cc2571e641e
https://github.com/Perl/perl5/commit/1221515648ebefa1a60a956275f62cc2571e641e
Author: Tony Cook <t...@develop-help.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M embed.fnc
M embed.h
M handy.h
M makedef.pl
M proto.h
M util.c
Log Message:
-----------
allow building with -DPERL_MEM_LOG on Win32
This appears to have been broken for a while, and became more broken
with 75acd14e, which made newSV_type() inline.
This will also prevent warnings about calls to undeclared functions
on systems that don't need symbols to be exported.
(cherry picked from commit bc726283c505c016567b3156526f1aeecc777244)
Commit: 8e81717cecd0253e19e525b077ffc71e9a55cd93
https://github.com/Perl/perl5/commit/8e81717cecd0253e19e525b077ffc71e9a55cd93
Author: Craig A. Berry <craigbe...@mac.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M configure.com
Log Message:
-----------
Future proof archname on VMS
OpenVMS x86_64 is out and should be getting a native (not cross)
C compiler Real Soon Now. So prepare for that and try to get the
archname in a fashion that will work for any future architectures.
(cherry picked from commit 144dfbc7545720fb0e6e8364370a991bdf8acf76)
Commit: 9d1d1f9fe397f3657061da481c663458b072cdbc
https://github.com/Perl/perl5/commit/9d1d1f9fe397f3657061da481c663458b072cdbc
Author: Tony Cook <t...@develop-help.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M embed.fnc
M proto.h
Log Message:
-----------
pp_sort: don't force inline the comparison functions
With gcc 12 when building with the -Og forcing inline causes the
build to fail, with the compiler complaining it can't inline
those functions.
With -O2, the functions are inlined anyway.
Note that -Og is the gcc recommended optimization option to build
with if you are going to debug the binary.
Fixes #20395
(cherry picked from commit f5a18896dd41b93e5e6e8227ada0f26cd0ebc352)
Commit: 1a4a6dfa87902852c5b99dbf5dd7d4c7bd10f837
https://github.com/Perl/perl5/commit/1a4a6dfa87902852c5b99dbf5dd7d4c7bd10f837
Author: Tony Cook <t...@develop-help.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M Configure
Log Message:
-----------
Configure: don't probe for the malloc()/free() return type
We require a C99 compiler, or in the case that led to this commit, a
C++ compiler, and for those the malloc() and free() return types are
well defined.
This probe broke on Solaris when building with g++.
Unlike glibc, the libc headers on Solaris, when building using a C++
compiler, define the stdlib.h functions within the std:: namespace,
then imports those names into the top level namespace with 'using
std::malloc'.
This conflicts with the declarations used in the probe, causing the
probe to fail to build, despite malloc() actually returning a void *.
Since these two functions have well defined return types according to
the standard, assume their return values match.
Configure can still be invoked with different definitions for
malloctype and freetype, or hints can override them, so someone on a
non-standard system can at least get past this if they really need to
(such a system will likely not build perl anyway.)
(cherry picked from commit d8a109ccd80350f5b83d0928d87032df3ec1b8dd)
Compare: https://github.com/Perl/perl5/compare/50b48d85285c...1a4a6dfa8790
