Skip to content

regen/locale.pl: Use 'USE_LOCALE" not 'NO_LOCALE' #23431

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: blead
Choose a base branch
from

Conversation

khwilliamson
Copy link
Contributor

NO_LOCALE is a Configure option used to override setting the internal
option USE_LOCALE. Internal checks should use the internal version.

Not doing this caused z/OS to think it should be using locales on
threaded systems, whereas it shouldn't.

FYI, the reason this is is that the OS refuses to change the locale at
all once a second thread is started. Perl relies on the ability to
change the locale at will to accommodate locales that have a comma be the
radix (decimal point) character and the huge amount of code that has
been written expecting that at all times a dot is the radix character.
This includes core code (which we could change) and XS code (which would
be overwhelming to change).
.

  • I'm unsure if this set of changes does requires a perldelta entry.

NO_LOCALE is a Configure option used to override setting the internal
option USE_LOCALE.  Internal checks should use the internal version.

Not doing this caused z/OS to think it should be using locales on
threaded systems, whereas it shouldn't.

FYI, the reason this is is that the OS refuses to change the locale at
all once a second thread is started.  Perl relies on the ability to
change the locale at will to accommodate locales that have a comma be the
radix (decimal point) character and the huge amount of code that has
been written expecting that at all times a dot is the radix character.
This includes core code (which we could change) and XS code (which would
be overwhelming to change).
It shouldn't be getting set anyway, but this makes it clear, and also
makes sure someone hasn't tried to define it with Configure
@bulk88
Copy link
Contributor

bulk88 commented Jul 12, 2025

I dont see anything wrong with this commit, fixing up usage of 2 #defines with direct opposite conflicting meanings is good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants