Use getlocalename_l() if available - #24666
Conversation
|
The change looks reasonable, but I assume you see the cygwin failure. As far as I can see cygwin is the only platform CI tests that has getlocalename_l(). |
|
As with many of my PRs, if they go smoothly fine; if not, it'll have to wait until I get time to dig further. In this case, I will need to get a current cygwin set up for debugging. Given that basically every OS we test on has some bug or another with locale handling, I'm more inclined to think this is their problem, and it just hasn't been tested sufficiently until we came along. But it's premature to make that assertion. I've converted this to draft |
It was recently placed in the wrong place in the list.
These are base level macros that need to be visible because they are called by generally visible higher level macros, but shouldn't be used by themselves; I think documenting them would encourage inappropriate use of them.
Rather than having a 12 element list, just document pTHX_1, and mention the others. But have X<> elements for all of them, and make sure in regen/embed.pl that they are all available to all code
|
I can't see how it could be anything other than a bug(s) in cygwin. It's dying in getlocalename_l() when called with category LC_ALL, and the object parameter has been set to the C locale. If instead I loop through the individual categories, it doesn't die and each properly returns C. That indicates it can't handle LC_ALL on this simple case. I'm not convinced that is the only bug. I presume they will want a non-Perl simple reproducer. |
|
https://cygwin.com/pipermail/cygwin/2026-August/259965.html It's easy to make it crash: |
5d0aae4 to
4d5e431
Compare
If nvtype is either double, DoubleDouble, or 80-bit extended precision long double, it checks the smallest possible positive value (aka DENORM_MIN). Else, (IEEE 754 long double or __float128), it checks a subnormal that's larger than DENORM_MIN. (It could easily be extended to cover DENORM_MIN for all nvtypes.) Contributed by Sisyphus in GH Perl#9388. Committer: arith2.t: Accommodate variable number of tests run When compiled with -Dusequadmath, one more element is added to @v in the 'unless' block starting at line 72. Hence, don't specify number of tests exactly; allow flexibility.
When saving a pointer to the just-matched string and copying the string,
`S_reg_set_capture_string` has a COW branch and a non-COW branch. Some
common code follows the two branches:
```
RXp_SUBCOFFSET(prog) = RXp_SUBOFFSET(prog);
if (RXp_SUBOFFSET(prog) && utf8_target) {
....
}
```
However, the COW branch concludes with:
```
RXp_SUBOFFSET(prog) = 0;
RXp_SUBCOFFSET(prog) = 0;
```
Since the common code cannot achieve anything in the COW case,
this commit moves it inside the non-COW branch.
The types Size_t and SSize_t were introduced in 5.000. STRLEN was introduced in 3.0.
There weren't releases for the intermediate versions, so they aren't dated.
This struct is visible to all code. I noticed in grepping metacpan that some modules use this spelling to refer to other things, so there is a potential clash. Since this is used only in generated code, it is easy to rename it to use a spelling reserved for Perl's use.
PERL_EXT_RE_BUILD was listed twice. Remove the one where it was unconditionally set false; retaining the more flexible, hence accurate, one.
I did some more grepping of the source to look for symbols that we can assume are undefined for general usage, cpan and darkpan. An example is PERL_EXT_POSIX (seeing that in the source prompted this endeavor). That symbol should only be defined when compiling the POSIX module, so any symbols created only while it is #defined, won't be visible to the outside world. I looked for "/ \b PERL_ \w+ /x" and scanned through the list. The result are the symbols added here, which showed that 5 symbols this previously thought were visible everywhere actually aren't. So they are removed from the list.
This works on ASCII boxes, but not otherwise. Instead use the macro named and designed for the purpose
This POSIX 2024 function solves long-standing thread unsafe behavior on platforms that properly implement it.
4d5e431 to
8e65e74
Compare
This POSIX 2024 function solves long-standing thread unsafe behavior on platforms that properly implement it.