Re: lib/malloca.c: warning about [-Wsign-compare]

[Bruno Haible]

Bjarni,

Please use the bug report template from
.

Bruno

lib/malloca.c: warning about [-Wsign-compare]

[Bjarni Ingi Gislason]

  Compilation with

Debian clang version 14.0.6-2
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Software: groff (git HEAD)

  CC   lib/libgnu_a-malloca.o
../lib/malloca.c:54:38: warning: comparison of integers of different
signs: 'unsigned long' and 'idx_t' (aka 'long') [-Wsign-compare]
  if (!ckd_add (, n, plus) && !xalloc_oversized (nplus, 1))
 ^~~
../lib/xalloc-oversized.h:62:33: note: expanded from macro 'xalloc_oversized'
# define xalloc_oversized(n, s) __xalloc_oversized (n, s)
^
../lib/xalloc-oversized.h:33:8: note: expanded from macro '__xalloc_oversized'
   < (n)))
   ^  ~
1 warning generated.
 

Re: bool and C23

[Bruno Haible]

Paul Eggert wrote:
> >   #include "unitypes.h"
> >   
> > +/* Get bool.  */
> > +#include 
> 
> In examples like these would it make sense to do the following instead? 
> 
>#if !@HAVE_C_BOOL@ && !defined __cplusplus
> #include 
>#endif

No, this would not work:
  * @HAVE_C_BOOL@ tests a property of the C compiler that has built
libunistring. It is unrelated to the compiler that uses 
after it has been installed in public locations.
  * As we have just discovered (re Sun C++), 'defined __cplusplus' is not
a guarantee that 'true' is defined correctly. So, even in C++ mode,
it may be a win to include . Remember, here we are in a
context where gl_C_BOOL / AC_C_BOOL has not been invoked.

Bruno

Re: bool and C23

[Bruno Haible]

Paul Eggert wrote:
> I did notice one glitch (an unnecessary "#undef true" that is always 
> commented out) and a couple of minor opportunities for simplification, 
> and installed the attached update.

OK.

> Use the slightly
> more-elegant ‘!true’ instead of ‘true == 1’; this shouldn’t matter
> in practice

Yes. At least with Sun C++ these two preprocessor expressions are equivalent.

Bruno

Re: lib/malloca.c: error when compiling "groff"

[Paul Eggert]

On 9/18/22 09:36, Bjarni Ingi Gislason wrote:

   The source of the compilation error was the file
"src/include/assert.h" in "groff".

   Removing it fixes the compilation.


This makes it sound like the problem was a leftover assert.h from a 
previous build, which is not a Gnulib bug per se. If so, we needn't 
change Gnulib.


If I'm wrong and there is a Gnulib bug, we need a self-contained recipe 
(e.g., a shell script anybody can run) for reproducing the problem. 
Bruno made some suggestions along that line in 
.

Re: bool and C23

[Paul Eggert]

On 9/18/22 10:10, Bruno Haible wrote:

   #define true (!false)
works! It evaluates to 1 and is of the right type.


Thanks, that's nicer than the tricky "#define true ((bool) +1)" that I 
was going to suggest.


I did notice one glitch (an unnecessary "#undef true" that is always 
commented out) and a couple of minor opportunities for simplification, 
and installed the attached update.From 154986613fe8d25d086568426b394098a6f2f7aa Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 18 Sep 2022 11:26:36 -0700
Subject: [PATCH] =?UTF-8?q?stdbool:=20omit=20=E2=80=98#undef=20true?=
 =?UTF-8?q?=E2=80=99?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is mostly just simplification.
* m4/c-bool.m4 (gl_C_BOOL): Test all preprocessors when
!HAVE_C_BOOL, not merely __SUNPRO_CC.  Use the slightly
more-elegant ‘!true’ instead of ‘true == 1’; this shouldn’t matter
in practice and if it does matter we want to know about it anyway.
Remove an unnecessary ‘#undef true’ that is simply commented out
by ‘configure’; again, if true is already #defined to be 0 the
system is so messed up we want to know about it anyway.
---
 ChangeLog| 12 
 m4/c-bool.m4 | 16 +++-
 2 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 87c370bd04..77862ed623 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2022-09-18  Paul Eggert  
+
+	stdbool: omit ‘#undef true’
+	This is mostly just simplification.
+	* m4/c-bool.m4 (gl_C_BOOL): Test all preprocessors when
+	!HAVE_C_BOOL, not merely __SUNPRO_CC.  Use the slightly
+	more-elegant ‘!true’ instead of ‘true == 1’; this shouldn’t matter
+	in practice and if it does matter we want to know about it anyway.
+	Remove an unnecessary ‘#undef true’ that is simply commented out
+	by ‘configure’; again, if true is already #defined to be 0 the
+	system is so messed up we want to know about it anyway.
+
 2022-09-18  Bruno Haible  
 
 	stdbool: Ensure that 'true' can be used in the preprocessor.
diff --git a/m4/c-bool.m4 b/m4/c-bool.m4
index 980de611b9..67c2cf2621 100644
--- a/m4/c-bool.m4
+++ b/m4/c-bool.m4
@@ -24,19 +24,17 @@ AC_DEFUN([gl_C_BOOL],
 
   dnl The "zz" puts this toward config.h's end, to avoid potential
   dnl collisions with other definitions.
-  dnl In C++ mode 'bool', 'true', 'false' are keywords and thus we don't need
-  dnl .  But in C mode, we do.
-  dnl Check __bool_true_false_are_defined to avoid re-including .
-  dnl In Sun C++ 5.11 (Solaris Studio 12.2) and older, 'true' as a preprocessor
-  dnl expression evaluates to 0, not 1.  Fix this by overriding 'true'.  Note
-  dnl that the replacement has to be of type 'bool'.
+  dnl If 'bool', 'true' and 'false' do not work, arrange for them to work.
+  dnl In C, this means including  if it is not already included.
+  dnl However, if the preprocessor mistakenly treats 'true' as 0,
+  dnl define it to a bool expression equal to 1; this is needed in
+  dnl Sun C++ 5.11 (Oracle Solaris Studio 12.2, 2010) and older.
   AH_VERBATIM([zzbool],
-[#if !defined HAVE_C_BOOL
+[#ifndef HAVE_C_BOOL
 # if !defined __cplusplus && !defined __bool_true_false_are_defined
 #  include 
 # endif
-# if defined __SUNPRO_CC && true != 1
-#  undef true
+# if !true
 #  define true (!false)
 # endif
 #endif])
-- 
2.37.3

Re: bool and C23

[Paul Eggert]

On 9/18/22 06:33, Bruno Haible wrote:

  #include "unitypes.h"
  
+/* Get bool.  */

+#include 


In examples like these would it make sense to do the following instead? 
This would avoid a bit of namespace pollution.


  #if !@HAVE_C_BOOL@ && !defined __cplusplus
   #include 
  #endif

Re: bool and C23

[Bruno Haible]

Paul Eggert wrote on 2022-09-10:
> I installed into Gnulib the stdbool patches ...
> 
> After we have more experience with this in Gnulib, we can start thinking 
> about updating Autoconf.

As part of this "gathering experience", I compiled a gnulib testdir with
various compilers on various systems.

No problems seen
  - with GCC,
  - with clang (I tested all versions from clang 3.9 to clang 14),
  - with AIX xlc and xlclang.

But with Sun C++ on Solaris 10 (SOS11, __SUNPRO_CC=0x580 [1]) and
11.3 (solstudio12.2, __SUNPRO_CC=0x5110 [1]) I get a compilation error:

CC -xarch=generic64 -O -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I../../gltests -I..   
-DGNULIB_STRICT_CHECKING=1  -DIN_GNULIB_TESTS=1  -I. -I../../gltests  -I.. 
-I../../gltests/..  -I../gllib -I../../gltests/../gllib 
-I/home/haible/prefix-x86_64/include -D_REENTRANT  -g -c -o test-stdbool-c++.o 
../../gltests/test-stdbool-c++.cc
"../../gltests/test-stdbool-c++.cc", line 33: Error: A declaration was expected 
instead of ""error: true is not 1"".
1 Error(s) detected.
*** Error code 1

This compiler defines _BOOL, to indicate that 'bool', 'true', 'false' are
keywords [2]. But in the preprocessor, 'true' evaluates to 0, not 1 !
Although cppreference.com does not clearly state that 'true' and 'false'
must be usable as in preprocessor directives, such a compiler behaviour
will show up as bugs in application programs, when more and more applications
use 'true' and 'false' instead of old-style '1' and '0'. Thus, I think we
should fix this compiler behaviour.

What can the replacement be?

  #define true 1
does not work, because it would be of type 'int' and thus not behave right
w.r.t. overloaded functions, such as
  int func (int);
  int func (bool);

  #define true ((bool) 1)
fixes the type, but is not usable in preprocessor expressions, since casts
are not allowed there.

  #define true (!false)
works! It evaluates to 1 and is of the right type.

Done through the attached patches. The second one should get included into
Autoconf's AC_C_BOOL, when that comes to exist.

[1] https://github.com/cpredef/predef/blob/master/Compilers.md
[2] https://docs.oracle.com/cd/E37069_01/html/E54439/uc-cc-1.html


2022-09-18  Bruno Haible  

stdbool: Ensure that 'true' can be used in the preprocessor.
* m4/c-bool.m4 (gl_C_BOOL): With Sun C++, redefine 'true' if it does not
evaluate to 1 in the preprocessor.

stdbool-c99: Ensure that 'true' can be used in the preprocessor.
* lib/stdbool.in.h (true): Redefine if it does not evaluate to 1 in the
preprocessor.
>From e73f9ba6b3286e4cf570c77cd38f6ceff00653ba Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Sun, 18 Sep 2022 18:45:39 +0200
Subject: [PATCH 1/2] stdbool-c99: Ensure that 'true' can be used in the
 preprocessor.

* lib/stdbool.in.h (true): Redefine if it does not evaluate to 1 in the
preprocessor.
---
 ChangeLog| 6 ++
 lib/stdbool.in.h | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 9b20b98d4a..3ea944f7d2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2022-09-18  Bruno Haible  
+
+	stdbool-c99: Ensure that 'true' can be used in the preprocessor.
+	* lib/stdbool.in.h (true): Redefine if it does not evaluate to 1 in the
+	preprocessor.
+
 2022-09-18  Bruno Haible  
 
 	uni{case,ctype,gbrk,str}/base: Fix installed .h file (regr. 2022-09-10).
diff --git a/lib/stdbool.in.h b/lib/stdbool.in.h
index 36f26560af..834c5f7e78 100644
--- a/lib/stdbool.in.h
+++ b/lib/stdbool.in.h
@@ -109,6 +109,13 @@ typedef enum { _Bool_must_promote_to_int = -1, false = 0, true = 1 } _Bool;
 #  define false false
 #  define true true
 # endif
+/* In Sun C++ 5.11 (Solaris Studio 12.2) and older, 'true' as a preprocessor
+   expression evaluates to 0, not 1.  Fix this by overriding 'true'.  Note that
+   the replacement has to be of type 'bool'.  */
+# if defined __SUNPRO_CC && true != 1
+#  undef true
+#  define true (!false)
+# endif
 #else
 # define false 0
 # define true 1
-- 
2.34.1

>From 16a1b6af1e618b22d621edc6054d4225cbcb98a1 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Sun, 18 Sep 2022 18:47:22 +0200
Subject: [PATCH 2/2] stdbool: Ensure that 'true' can be used in the
 preprocessor.

* m4/c-bool.m4 (gl_C_BOOL): With Sun C++, redefine 'true' if it does not
evaluate to 1 in the preprocessor.
---
 ChangeLog|  4 
 m4/c-bool.m4 | 20 +++-
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 3ea944f7d2..87c370bd04 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
 2022-09-18  Bruno Haible  
 
+	stdbool: Ensure that 'true' can be used in the preprocessor.
+	* m4/c-bool.m4 (gl_C_BOOL): With Sun C++, redefine 'true' if it does not
+	evaluate to 1 in the preprocessor.
+
 	stdbool-c99: Ensure that 'true' can be used in the preprocessor.
 	* lib/stdbool.in.h (true): Redefine if it does not evaluate to 1 in the
 	preprocessor.
diff --git a/m4/c-bool.m4 b/m4/c-bool.m4

Re: lib/malloca.c: error when compiling "groff"

[Bjarni Ingi Gislason]

  The source of the compilation error was the file
"src/include/assert.h" in "groff".

  Removing it fixes the compilation.

Re: bool and C23

[Bruno Haible]

Paul Eggert wrote:
> I installed into Gnulib the stdbool patches ...

The changes to the files
  lib/unicase.in.h
  lib/unictype.in.h
  lib/unigbrk.in.h
  lib/unistr.in.h
are not good, because these files ultimately get installed as public header
files:
  1. They get copied to libunistring, with  replaced with
 .
  2. They get installed by "make install".
  3. The user uses them with a compiler that maybe is only C99 compliant.

I did not see this during the review. But the continuous integration caught it.


2022-09-18  Bruno Haible  

uni{case,ctype,gbrk,str}/base: Fix installed .h file (regr. 2022-09-10).
* lib/unicase.in.h: Do include .
* lib/unictype.in.h: Likewise.
* lib/unigbrk.in.h: Likewise.
* lib/unistr.in.h: Likewise.

diff --git a/lib/unicase.in.h b/lib/unicase.in.h
index 5317cd3dd8..9bcc79edd8 100644
--- a/lib/unicase.in.h
+++ b/lib/unicase.in.h
@@ -27,6 +27,9 @@
 
 #include "unitypes.h"
 
+/* Get bool.  */
+#include 
+
 /* Get size_t.  */
 #include 
 
diff --git a/lib/unictype.in.h b/lib/unictype.in.h
index de6a191d87..2f0efefca8 100644
--- a/lib/unictype.in.h
+++ b/lib/unictype.in.h
@@ -19,6 +19,9 @@
 
 #include "unitypes.h"
 
+/* Get bool.  */
+#include 
+
 /* Get size_t.  */
 #include 
 
diff --git a/lib/unigbrk.in.h b/lib/unigbrk.in.h
index 7fbc2a0d57..f1b60e17b9 100644
--- a/lib/unigbrk.in.h
+++ b/lib/unigbrk.in.h
@@ -26,6 +26,9 @@
 #ifndef _UNIGBRK_H
 #define _UNIGBRK_H
 
+/* Get bool.  */
+#include 
+
 /* Get size_t. */
 #include 
 
diff --git a/lib/unistr.in.h b/lib/unistr.in.h
index 40c7929575..4d48751558 100644
--- a/lib/unistr.in.h
+++ b/lib/unistr.in.h
@@ -19,6 +19,9 @@
 
 #include "unitypes.h"
 
+/* Get bool.  */
+#include 
+
 /* Get size_t, ptrdiff_t.  */
 #include 
 

signal: Fix a C++ compilation error due to sched_yield on OpenBSD 6.0

[Bruno Haible]

On OpenBSD 6.0, I'm seeing this compilation error:

depbase=`echo test-sched-c++.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I../../gltests -I..  
-DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I. -I../../gltests -I.. 
-I../../gltests/.. -I../gllib -I../../gltests/../gllib -I/home/bruno/include 
-Wall  -Wno-error -g -O2 -MT test-sched-c++.o -MD -MP -MF $depbase.Tpo -c -o 
test-sched-c++.o ../../gltests/test-sched-c++.cc &&\
mv -f $depbase.Tpo $depbase.Po
In file included from /usr/include/pthread.h:47,
 from ../gllib/pthread.h:46,
 from ../gllib/signal.h:68,
 from ../gllib/sys/select.h:119,
 from /usr/include/sys/types.h:230,
 from ../gllib/sys/types.h:39,
 from /usr/include/sched.h:42,
 from ../gllib/sched.h:30,
 from ../../gltests/test-sched-c++.cc:22:
../gllib/sched.h: In member function 'gnulib::_gl_sched_yield_wrapper::operator 
int (*)()() const':
../gllib/sched.h:566: error: '::sched_yield' has not been declared
gmake[4]: *** [Makefile:23347: test-sched-c++.o] Error 1

The problem here is not that sched_yield is not declared, but rather that its
declaration comes too late, due to the sequence of #includes.

sched_yield is declared at /usr/include/sched.h:65
and used at gllib/sched.h:566.

test-sched-c++.cc:22 -> ../gllib/sched.h
../gllib/sched.h:30 -> /usr/include/sched.h
/usr/include/sched.h:42 -> ../gllib/sys/types.h
../gllib/sys/types.h:39 -> /usr/include/sys/types.h
/usr/include/sys/types.h:230 -> ../gllib/sys/select.h
../gllib/sys/select.h:119 -> ../gllib/signal.h<-- HERE1
../gllib/signal.h:68 -> ../gllib/pthread.h<-- HERE2
../gllib/pthread.h:46 -> /usr/include/pthread.h
/usr/include/pthread.h:47 -> ./gllib/sched.h
../gllib/sched.h:30 -> /usr/include/sched.h
 declares sched_yield

The natural places to cut down the #include forest is at HERE1 or HERE2.
And indeed the one at HERE2 is not needed any more in OpenBSD ≥ 5.1.
Thus, this patch fixes the issue.


2022-09-18  Bruno Haible  

signal: Fix a C++ compilation error due to sched_yield on OpenBSD 6.0.
* lib/signal.in.h: On OpenBSD, include . Don't include
 on OpenBSD ≥ 5.1.

diff --git a/lib/signal.in.h b/lib/signal.in.h
index 5d2d80c99d..c0d4848db0 100644
--- a/lib/signal.in.h
+++ b/lib/signal.in.h
@@ -55,12 +55,19 @@
 #ifndef _@GUARD_PREFIX@_SIGNAL_H
 #define _@GUARD_PREFIX@_SIGNAL_H
 
-/* Mac OS X 10.3, FreeBSD < 8.0, OpenBSD 3.8, OSF/1 4.0, Solaris 2.6, Android,
+/* For testing the OpenBSD version.  */
+#if (@GNULIB_PTHREAD_SIGMASK@ || defined GNULIB_POSIXCHECK) \
+&& defined __OpenBSD__
+# include 
+#endif
+
+/* Mac OS X 10.3, FreeBSD < 8.0, OpenBSD < 5.1, OSF/1 4.0, Solaris 2.6, 
Android,
OS/2 kLIBC declare pthread_sigmask in , not in .
But avoid namespace pollution on glibc systems.*/
 #if (@GNULIB_PTHREAD_SIGMASK@ || defined GNULIB_POSIXCHECK) \
 && ((defined __APPLE__ && defined __MACH__) \
-|| (defined __FreeBSD__ && __FreeBSD__ < 8) || defined __OpenBSD__ \
+|| (defined __FreeBSD__ && __FreeBSD__ < 8) \
+|| (defined __OpenBSD__ && OpenBSD < 201205) \
 || defined __osf__ || defined __sun || defined __ANDROID__ \
 || defined __KLIBC__) \
 && ! defined __GLIBC__