bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org
Cc: Bjarni Ingi Gislason <bjarniig@simnet.is>
Subject: Re: module c-nullptr: error compiling groff
Date: Mon, 06 Feb 2023 04:27:18 +0100	[thread overview]
Message-ID: <6051252.riuWyFgYyT@nimes> (raw)
In-Reply-To: <Y+BIY5mIq21bR0Po@localhost>

Bjarni Ingi Gislason wrote:
> Debian testing (bookworm/sid)
> gcc (Debian 12.2.0-14) 12.2.0
> GNU Make
> [...]
>   CXX      src/roff/troff/env.o
> In file included from /usr/include/c++/12/bits/stl_bvector.h:61,
>                  from /usr/include/c++/12/vector:65,
>                  from ../src/roff/troff/charinfo.h:20,
>                  from ../src/roff/troff/env.cpp:31:
> /usr/include/c++/12/bits/functional_hash.h:273:12: error: redefinition of 'struct std::hash<long int>'
>   273 |     struct hash<nullptr_t> : public __hash_base<size_t, nullptr_t>
>       |            ^~~~~~~~~~~~~~~
> /usr/include/c++/12/bits/functional_hash.h:157:3: note: previous definition of 'struct std::hash<long int>'
>   157 |   _Cxx_hashtable_define_trivial_hash(long)
>       |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> make[1]: *** [Makefile:10126: src/roff/troff/env.o] Error 1

Thanks for the report.

I reproduce it with the just-added unit tests, with GCC 11 or 12, but not
with other compilers (GCC 10 or older, clang, MSVC, AIX xlc, Solaris cc).

But even when there is no error in the unit test, there could be errors
in application code, if we define nullptr to some value that is inferior
to what the C++ compiler already does. So, the guideline should be: If the
C++ compiler already supports 'nullptr', leave it alone and don't define
it as a macro.

I found out that for g++ and clang++, 'nullptr' is supported with the
options -std=c++11, -std=c++14, -std=c++17 and not supported with the
option -std=c++03. To detect this situation, the value of __cplusplus
can be used. The various __cpp_* macros don't help here.

Also, MSVC 14 supports it, although its __cplusplus value is only

In my tests, AIX xlc and Solaris cc (up to Developer Studio 12.6)
don't support it.

Taken together, this gives this fix.

2023-02-05  Bruno Haible  <bruno@clisp.org>

	c-nullptr: Fix conflict with libstdc++ in GCC >= 11.
	Reported by Bjarni Ingi Gislason <bjarniig@simnet.is> in
	* m4/c-nullptr.m4 (gl_C_NULLPTR): Don't define nullptr if it is already
	defined. In C++ mode, ignore the result of the configure test and don't
	define it when we know that the C++ compiler already supports it.

diff --git a/m4/c-nullptr.m4 b/m4/c-nullptr.m4
index af79854696..960eeff18d 100644
--- a/m4/c-nullptr.m4
+++ b/m4/c-nullptr.m4
@@ -18,13 +18,25 @@ AC_DEFUN([gl_C_NULLPTR],
-[#ifndef HAVE_C_NULLPTR
-# ifndef __cplusplus
-#  define nullptr ((void *) 0)
-# elif 3 <= __GNUG__
-#  define nullptr __null
+[#ifndef nullptr /* keep config.h idempotent */
+# ifdef __cplusplus
+/* For the C++ compiler the result of the configure test is irrelevant.
+   We know that at least g++ and clang with option -std=c++11 or higher, as well
+   as MSVC 14 or newer, already have nullptr.  */
+#  if !(((defined __GNUC__ || defined __clang__) && __cplusplus >= 201103L) \
+        || (defined _MSC_VER && 1900 <= _MSC_VER))
+/* Define nullptr as a macro, the best we can.  */
+#   if 3 <= __GNUG__
+#    define nullptr __null
+#   else
+#    define nullptr 0L
+#   endif
+#  endif
 # else
-#  define nullptr 0L
+/* For the C compiler, use the result of the configure test.  */
+#  ifndef HAVE_C_NULLPTR
+#   define nullptr ((void *) 0)
+#  endif
 # endif

  reply	other threads:[~2023-02-06  3:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-06  0:22 module c-nullptr: error compiling groff Bjarni Ingi Gislason
2023-02-06  3:27 ` Bruno Haible [this message]
2023-02-06  5:10   ` Paul Eggert
2023-02-06 11:13     ` Bruno Haible
2023-02-07 21:50     ` Bruno Haible

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6051252.riuWyFgYyT@nimes \
    --to=bruno@clisp.org \
    --cc=bjarniig@simnet.is \
    --cc=bug-gnulib@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).