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.])
Thanks for mentioning that. lib/strftime.c's comment suggests 'false', which is why I defined it to 'false'.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.
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.
From 3d041f83c60240db782663908da219fc1144915f Mon Sep 17 00:00:00 2001 From: Paul Eggert <egg...@cs.ucla.edu> Date: Sun, 7 Sep 2025 16:34:43 -0700 Subject: [PATCH] maint: allow false/true in C macros MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * top/maint.mk (sc_Wundef_boolean): Allow false and true in C macro definiens. C23 requires support for false and true, and the ‘bool’ module makes it easy to support this in older compilers. --- ChangeLog | 7 +++++++ top/maint.mk | 7 +++++-- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 2ff90ef8b7..0c132816f4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2025-09-07 Paul Eggert <egg...@cs.ucla.edu> + + maint: allow false/true in C macros + * top/maint.mk (sc_Wundef_boolean): Allow false and true in C + macro definiens. C23 requires support for false and true, and the + ‘bool’ module makes it easy to support this in older compilers. + 2025-09-07 Bruno Haible <br...@clisp.org> bootstrap: Improve efficiency of "git clone". diff --git a/top/maint.mk b/top/maint.mk index e03e887cba..1a6511b4f8 100644 --- a/top/maint.mk +++ b/top/maint.mk @@ -1454,10 +1454,13 @@ sc_prohibit_reversed_compare_failure: # That would be flagged by using -Wundef, however gnulib currently # tests many undefined macros, and so we can't enable that option. # So at least preclude common boolean strings as macro values. +# Although this rule formerly also complained about 'true' and 'false', +# that complaint is now incorrect given that C23 has blessed this practice +# and the 'bool' module supports it. sc_Wundef_boolean: - @prohibit='^#define.*(yes|no|true|false)$$' \ + @prohibit='^#define.*(yes|no)$$' \ in_files='$(CONFIG_INCLUDE)' \ - halt='Use 0 or 1 for macro values' \ + halt='Use 0/1 or false/true for macro values' \ $(_sc_search_regexp) # Even if you use pathmax.h to guarantee that PATH_MAX is defined, it might -- 2.48.1
