On 2025-09-07 15:00, Bruno Haible wrote:
> I'm not even sure what you
> mean by "Do not worry about multibyte C locales."

I meant to not worry about platforms where the "C" (not "C.utf8") locale 
is multibyte. I don't know of how diffutils would misbehave in such 
locales (other than not be strictly POSIX-conforming in unusual cases 
where native tools aren't either), so I wanted Gnulib to not worry about 
the possibility.


> The two functions hard_locale_LC_MESSAGES and hard_locale_LC_TIME
> look like heuristics to me; I wouldn't bet that they are correct
> in all situations.

For what it's worth, GNU Emacs has used a similar heuristic for a decade 
(see emacs/src/emacs.c's using_utf8) without reported trouble. 
Admittedly this part of Emacs is not the mainline as Emacs normally uses 
its own UTF-8 decoder, but I think it unlikely that the mentioned 
functions will misbehave in practice (and if they do, surely can fix 
them without needing support for multithreading and locks).

To some extent everything in this area is a heuristic, even Gnulib's 
hard_locale which is what diffutils formerly used. If the heuristic 
works in practice, that's good enough.


> +AC_DEFINE([SUPPORT_NON_GREG_CALENDARS_IN_STRFTIME], [false],
> +  [Do not worry about GNU strftime behavior for non-Gregorian calendars.])

> Either SUPPORT_NON_GREG_CALENDARS_IN_STRFTIME needs to be defined to 0,
> not false. Or the syntax check sc_Wundef_boolean needs to be tweaked.
Thanks for mentioning that. lib/strftime.c's comment suggests 'false', 
which is why I defined it to 'false'.

These days it should be OK to use 'true' and 'false' due to C23 and the 
near-ubiquitous use of the 'bool' module, so I installed the attached.