Subject: bug#79382: commit e124541148d38cd8b7f962aceb72fb44e7cc0aab

From: Paul Eggert <[email-masked]>
Date: Sun, 7 Sep 2025 17:00:31 -0700

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.

From 3d041f83c60240db782663908da219fc1144915f Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email-masked]>
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  <[email-masked]>
+
+	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  <[email-masked]>
 
 	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