bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

stdbool module unconditionally #define true


From: Simon Josefsson
Subject: stdbool module unconditionally #define true
Date: Fri, 14 Oct 2022 21:16:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Hi.

Upgrading gnulib in inetutils causes a build failure:

rlogind.c: In function 'rlogind_mainloop':
rlogind.c:1112:7: error: expected identifier or '(' before numeric constant
 1112 |   int true;
      |       ^~~~

The file does not include stdbool.h.  Apparently this has worked for
many years and on many platforms.  One may question the wisdom to name a
variable 'true' but apparently it seemed to have worked well, and the
code may originate back before stdbool was introduced into C.

Does C23 disallow this?

I see config.h contains the following (I'm using gcc 10):

/* Define to 1 if bool, true and false work as per C2023. */
/* #undef HAVE_C_BOOL */
...
#ifndef HAVE_C_BOOL
# if !defined __cplusplus && !defined __bool_true_false_are_defined
#  if HAVE_STDBOOL_H
#   include <stdbool.h>
#  else
#   if defined __SUNPRO_C
#    error "<stdbool.h> is not usable with this configuration. To make it 
usable, add -D_STDC_C99= to $CC."
#   else
#    error "<stdbool.h> does not exist on this platform. Use gnulib module 
'stdbool-c99' instead of gnulib module 'stdbool'."
#   endif
#  endif
# endif
# if !true
#  define true (!false)
# endif
#endif

This seems surprising to me -- the snippet comes from m4/c-bool.m4 and
always introduce a #define for the CPP symbol 'true', even when the code
did not request any stdbool-related declarations by doing '#include
<stdbool.h>'.

Shouldn't gnulib provide a stdbool.h file that #define true, instead of
putting it into config.h forcing it on all code?

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]