t/date.t panics on Perl 5.42.0 Darwin: nl_langinfo locale codeset empty

[toddr-bot]

Summary

t/date.t fails with SIGABRT on Perl 5.42.0 (Darwin/macOS) when locale-aware date formatting is exercised. The process panics inside Perl's internal locale.c when nl_langinfo(CODESET) returns an empty string for the en_GB locale.

CPAN Testers Report

• Report: https://matrix.perl-magpie.org/results/112e1688-588b-11f1-8f7a-c7076ef0156f
• Distribution: Template-Toolkit-3.106
• Perl: v5.42.0 (perlbrew)
• OS: Darwin (macOS, darwin-2level, ARM/Homebrew)
• Tester: Nigel Horne
• Grade: FAIL

Error

Template process failed: undef error - locale.c: 6632: panic: nl_langinfo returned empty
for 0 in supposed locale 'en_GB'; which really is 'en_GB'
 codeset is ''; radix='.'; January='January'; strtod(1,5)=1, strtod(1.5)=1.5

The panic occurs at the first locale-using test (test block 8 in t/date.t):

[% USE english = date(format => '%A', locale => 'en_GB') %]
[% english.format %]

The call chain is: Template::Plugin::Date::format() → POSIX::setlocale(LC_ALL, 'en_GB') → _strftime() → Perl's internal locale.c panics because nl_langinfo(CODESET) returns empty for the en_GB locale on this macOS system.

Impact

• 22 of 39 subtests reported as failed
• Process killed by SIGABRT (Wstat: 6, Signal: ABRT) after test 19
• "Bad plan. You planned 39 tests but ran 19" — the abort killed the process mid-run
• Only 1 of 121 test programs failed; all 3278 other subtests passed

Analysis

This appears to be a Perl 5.42.0 core issue, not a Template Toolkit bug. The setlocale(LC_ALL, 'en_GB') call succeeds (returns 'en_GB'), but Perl's internal locale validation in locale.c then panics when nl_langinfo returns an empty codeset. This is new behavior in Perl 5.42.0 — the same locale handling works on earlier Perl versions.

The en_GB locale on macOS (without a codeset suffix like .UTF-8) may legitimately have an empty codeset from nl_langinfo, but previous Perl versions did not treat this as a fatal condition.

Possible Mitigations

Template Toolkit could work around this by:

1. Appending .UTF-8 to locale names that lack a codeset suffix — the plugin already tries suffixes like .ISO8859-1 and .UTF-8 in @LOCALE_SUFFIX, but the bare en_GB matches first (since setlocale accepts it) and the suffix loop stops. The logic at lib/Template/Plugin/Date.pm:167-176 could be changed to prefer a locale with a codeset suffix when available.

2. Using LC_TIME instead of LC_ALL — the plugin only needs time/date formatting, so setlocale(LC_TIME, ...) would be more targeted and might avoid triggering the nl_langinfo(CODESET) check.

3. Wrapping the strftime call in eval — catch the panic before it kills the process (though SIGABRT from locale.c may not be catchable).

However, this should also be reported upstream to Perl — panicking on a locale that setlocale() itself accepted is arguably a Perl bug.

---

🤖 Created by Kōan from CPAN Testers analysis

[toddr]

@toddr-bot produce a small perl one liner that reproduces this failure without needing any template modules.

[toddr-bot]

Here's a minimal one-liner that reproduces the panic on Perl 5.42.0 + macOS without any Template modules:

perl -MPOSIX -e 'setlocale(LC_ALL, "en_GB") and print strftime("%A", localtime)'

This does exactly what Template::Plugin::Date does under the hood:

1. Sets LC_ALL to the bare en_GB locale (no codeset suffix)
2. Calls strftime, which triggers Perl's internal nl_langinfo(CODESET) check

On Perl 5.42.0 Darwin, step 2 panics because nl_langinfo returns an empty codeset for the en_GB locale that setlocale itself accepted.

On older Perls or Linux, it prints Monday (or whatever day it is) without issue.

If the en_GB locale isn't installed on the test system, this variant forces the same code path with any bare locale (no .UTF-8 suffix):

perl -MPOSIX -e 'for my $loc (qw(en_GB fr_FR de_DE C)) { if (setlocale(LC_ALL, $loc)) { print "locale=$loc: ", strftime("%A", localtime), "\n" } }'

The panic only fires for locales where nl_langinfo(CODESET) returns empty — typically bare locale names on macOS that lack a codeset suffix like .UTF-8.