Branch: refs/heads/maint-5.38
Home: https://github.com/Perl/perl5
Commit: e2fd48070e9b60dcd72e67f5974857301c17081a
https://github.com/Perl/perl5/commit/e2fd48070e9b60dcd72e67f5974857301c17081a
Author: Yves Orton <demer...@gmail.com>
Date: 2025-01-05 (Sun, 05 Jan 2025)
Changed paths:
M regcomp.c
Log Message:
-----------
regcomp.c - zero the pRExC_state structure early in compilation
And initialize various members, especially RExC_mysv1 and RExC_mysv2
as early as possible under debugging.
Under -Uusedl we were ending up with the mysv1 and mysv2 slots set to
random pointers as the structure wasnt zeroed properly, and the
initialization for the temporary sv's wasn't performed correctly, which
then lead to segfaults.
Arguably we should have been using Zero() from the very beginning, as
we have had multiple bugs over the years where we added a member to
the structure but forgot to zero it at the start of compilation. This
change rectifies that and will prevent future oversights.
(cherry picked from commit ecbf63ae7dd6638fee8184d452ebacf312c3b535)
Commit: b947b06e677fccfc58cdcae011adb5fb89459373
https://github.com/Perl/perl5/commit/b947b06e677fccfc58cdcae011adb5fb89459373
Author: Tony Cook <t...@develop-help.com>
Date: 2025-01-05 (Sun, 05 Jan 2025)
Changed paths:
M regcomp.c
M regcomp_internal.h
Log Message:
-----------
safer cleanup when failing to compile regexps
Prior to this commit when producing a warning the regexp compiler
would check if the warning category was marked as FATAL, and if it was
it would add clean up to the save stack to release buffers used during
compilation and to release the working REGEXP SV.
This causes two type of problems:
- if an error was already queued, Perl_ck_warner() returns even if
the warning is fatal, this meant that the normal clean up code
Perl_re_op_compile() would also run, resulting in a double free
of the buffers.
- without fatal warnings, if a $SIG{__WARN__} handler died, the
buffers and the working REGEXP SV would leak.
Avoid this by using SAVEDESTRUCTOR_X() to release the memory and
optionally the SV at the end of scope.
Fixes #21661
(cherry picked from commit 388bf71121e682302397a8b7d9f56fef5ba2559e)
Commit: cc61c7c324dca235ae66df9aead03d29f50ff199
https://github.com/Perl/perl5/commit/cc61c7c324dca235ae66df9aead03d29f50ff199
Author: Tony Cook <t...@develop-help.com>
Date: 2025-01-05 (Sun, 05 Jan 2025)
Changed paths:
M t/re/pat.t
Log Message:
-----------
add tests for #21661
(cherry picked from commit c9e5693c3bd5a506e29ece21256a1c07a6668a8e)
Commit: 5153d4d9b6462aa14a884cd505c013bea1f8617e
https://github.com/Perl/perl5/commit/5153d4d9b6462aa14a884cd505c013bea1f8617e
Author: Karl Williamson <k...@cpan.org>
Date: 2025-01-05 (Sun, 05 Jan 2025)
Changed paths:
M locale.c
Log Message:
-----------
Fix locale initialization bug
On systems that have POSIX 2008 locales and haven't implemented a means
to find out what the current locale is, perl emulates this capability,
as best it can.
(Not having this capability is a defect in the POSIX standard, which has
been finally remedied in POSIX 2024
https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/getlocalename_l.html
but it will take time for implementations to catch up.)
In the absence of guidance from the Standard, some vendors created such
a means of getting this information, typically through a libc call named
'querylocale()'.
Perl uses whatever means is available and not buggy. (Unfortunately
there are bugs or glitches in many of the implementations, so perl
doesn't use those.)
But when it doesn't have a useful means to get this information, perl
implements an emulation of it. This works by perl trying to intercept
all changes to the locale and storing the new value, so that the
querylocale() emulation can simply return that when asked.
To save cycles, when asked to change the locale, perl skips actually
doing the change if it thinks it would be a no-op, that the new value is
the same as the old value.
Perl starts off setting itself to use the C locale and then reads the
environment to switch to what that specifies.
This bug here is that perl failed to tell the querylocale emulation at
the start that it was really in the C locale. Due to the way initialization
proceeds, the querylocale emulation thought that perl was already in the
locale specified by the environment, so the code that changes the locale
skipped any changes.
This commit merely initializes the querylocale emulation records to C.
That way, if the environment specifies a different locale, perl knows it
isn't a no-op and does the change.
On glibc systems, there is a (mostly undocumented) means of finding the
current locale that turns out to work well. Perl can use this. In 5.38
we didn't know that it was reliable, given its undocumented status, so
it was by default turned off. In 5.40, it is by default on. This bug
does not come up if it is enabled. To enable, call Configure adding the
option -Accflags=-DUSE_NL_LOCALE_NAME
(cherry picked from commit ecd3fa85b9609c4f3f1461d38604dc03854b1899)
Compare: https://github.com/Perl/perl5/compare/41de27bd655b...5153d4d9b646
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
