Branch: refs/heads/maint-5.38
Home: https://github.com/Perl/perl5
Commit: 9b5031be4156ab642f7c208158336596bf58ab53
https://github.com/Perl/perl5/commit/9b5031be4156ab642f7c208158336596bf58ab53
Author: Tony Cook <t...@develop-help.com>
Date: 2024-10-06 (Sun, 06 Oct 2024)
Changed paths:
M pad.c
M t/op/lexsub.t
Log Message:
-----------
cv_undef_flags: there's nothing to clean up for our subs in cloned pads
Fixes #21067
When an instance of a closure is created, the pad entries for the
cloned sub are copied (S_clone_sv_pad()) from either the prototype
sub (for lexicals belonging to the sub) or from the context (for
lexicals from outside
the sub).
This doesn't happen for our variables, instead the cloned sub has
these pad entries set to NULL.
This isn't an issue at runtime since references to lexical our
sub/variables are compiled into GV or GVSV ops.
cv_undef_flags() assumed this these entries were non-NULL for all
lexical subs.
Fix by checking if the entry is an our sub and the CV being freed is
a clone, if so, skip the accesses to the NULL pad entry.
Added an assert to the new branch to ensure any changes in the above
results in an early failure here and hopefully a fix.
(cherry picked from commit 59b78810094a841d3440b02afec38a629732062c)
Commit: d7662afd17b84f7bfd1c02b2c02cf0f7eecb1eae
https://github.com/Perl/perl5/commit/d7662afd17b84f7bfd1c02b2c02cf0f7eecb1eae
Author: Richard Leach <richardle...@users.noreply.github.com>
Date: 2024-10-06 (Sun, 06 Oct 2024)
Changed paths:
M av.c
M t/op/array.t
Log Message:
-----------
Perl_av_extend_guts: Zero() trailing elements after unshift & resize
Since
https://github.com/Perl/perl5/commit/399fef93c903aedee05a74de780b57eeeb571b32,
trailing elements in an array that has been unshifted and resized
might not be properly Zero() initialized. This is because of faulty
arithmetic when calculating `to_null`, the number of elements to
initialize, when the array was only partially shifted.
This commit corrects the arithmetic, adds comments arount the
calculation of `to_null`, and adds a test based upon the case
provided in GH #21235.
The test added segfaults more reliably for me - almost every time -
than the originally supplied case. However, since it relies upon
uninitialized memory, it's probably still not deterministic and
somewhat dependent upon the choice of memory allocator.
Closes #21235
(cherry picked from commit 9e298ab597b2c6fc0741749d7e29119e2d6cd628)
Commit: 271bd1973ff4f89a1ed2bd6980fdcca02882399c
https://github.com/Perl/perl5/commit/271bd1973ff4f89a1ed2bd6980fdcca02882399c
Author: Tony Cook <t...@develop-help.com>
Date: 2024-10-06 (Sun, 06 Oct 2024)
Changed paths:
M op.c
M t/lib/warnings/gv
Log Message:
-----------
make sure "use VERSION;" sets the flag needed for "used only once"
There's two parts to producing the "used only once" warning:
1. In a lexical scope with WARN_ONCE enabled, new GVs are
created with the GVf_MULTI flag off, a second mention of such a
name will set that flag.
2. After compilation, if G_WARN_ONCE is set in PL_dowarn, the entire
package tree is walked to report names which don't have GVf_MULTI set.
In this case G_WARN_ONCE wasn't being set, so the second part didn't
happen.
This flag is global, so using any other module that happened to
enable the WARN_ONCE flag (anything that does C<use warnings;>)
would allow warnings to be produced after compilation.
Fixes #21271
(cherry picked from commit 3c849777973e02cafe9c5064fafc43feb0c4e466)
Compare: https://github.com/Perl/perl5/compare/3d318a701ce8...271bd1973ff4
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
