bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
* module c-nullptr: error compiling groff
@ 2023-02-06  0:22 Bjarni Ingi Gislason
  2023-02-06  3:27 ` Bruno Haible
  0 siblings, 1 reply; 5+ messages in thread
From: Bjarni Ingi Gislason @ 2023-02-06  0:22 UTC (permalink / raw)
  To: bug-gnulib

Debian testing (bookworm/sid)

gcc (Debian 12.2.0-14) 12.2.0

GNU Make 4.4.0.90


[...]
  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
make[1]: Leaving directory '/home/bg/git/groff/build'
make: *** [Makefile:6847: all] Error 2

modules in bootstrap.conf:

gnulib_modules="
    git-version-gen
    havelib
    manywarnings
    wcwidth
    fprintf-posix
    gen-header
    snprintf
    vsnprintf-posix
    warnings
  mkstemp
  fmod
  getcwd
  putenv
  strcase
  strerror
  strtol
  setlocale
  stdckdint
  assert
  assert-h
  idx
  string
  strings
  c-nullptr
 "
#  c-nullptr causes an error when compiling (5. Feb. 2023)



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: module c-nullptr: error compiling groff
  2023-02-06  0:22 module c-nullptr: error compiling groff Bjarni Ingi Gislason
@ 2023-02-06  3:27 ` Bruno Haible
  2023-02-06  5:10   ` Paul Eggert
  0 siblings, 1 reply; 5+ messages in thread
From: Bruno Haible @ 2023-02-06  3:27 UTC (permalink / raw)
  To: bug-gnulib; +Cc: Bjarni Ingi Gislason

Bjarni Ingi Gislason wrote:
> Debian testing (bookworm/sid)
> 
> gcc (Debian 12.2.0-14) 12.2.0
> 
> GNU Make 4.4.0.90
> 
> 
> [...]
>   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
199711L.

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
	<https://lists.gnu.org/archive/html/bug-gnulib/2023-02/msg00030.html>.
	* 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],
 ])
 
   AH_VERBATIM([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
 #endif])
 ])







^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: module c-nullptr: error compiling groff
  2023-02-06  3:27 ` Bruno Haible
@ 2023-02-06  5:10   ` Paul Eggert
  2023-02-06 11:13     ` Bruno Haible
  2023-02-07 21:50     ` Bruno Haible
  0 siblings, 2 replies; 5+ messages in thread
From: Paul Eggert @ 2023-02-06  5:10 UTC (permalink / raw)
  To: Bruno Haible, bug-gnulib; +Cc: Bjarni Ingi Gislason

Thanks for fixing it so quickly.

On 2023-02-05 19:27, Bruno Haible wrote:

> +# 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))

<https://en.cppreference.com/w/cpp/language/nullptr> says nullptr is 
part of C++11, so would it be better to omit the "(defined __GNUC__ || 
defined __clang__) && "? It seems unlikely that a compiler would 
advertise conformance to C++11 without supporting nullptr.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: module c-nullptr: error compiling groff
  2023-02-06  5:10   ` Paul Eggert
@ 2023-02-06 11:13     ` Bruno Haible
  2023-02-07 21:50     ` Bruno Haible
  1 sibling, 0 replies; 5+ messages in thread
From: Bruno Haible @ 2023-02-06 11:13 UTC (permalink / raw)
  To: bug-gnulib, Paul Eggert; +Cc: Bjarni Ingi Gislason

Paul Eggert wrote:
> > +# 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))
> 
> <https://en.cppreference.com/w/cpp/language/nullptr> says nullptr is 
> part of C++11, so would it be better to omit the "(defined __GNUC__ || 
> defined __clang__) && "? It seems unlikely that a compiler would 
> advertise conformance to C++11 without supporting nullptr.

Unlikely?! You must be joking. We have seen so many occurrences where
compilers define __STDC_VERSION__ to a certain value without implementing
the corresponding standard entirely and correctly. Why should it be different
with __cplusplus? It is a common human behaviour to claim "we have XYZ!"
when in fact they only have 90% of XYZ.

In this particular case,
  - if we leave 'nullptr' alone although the compiler doesn't support it,
    there will be a compilation error quickly,
  - if we define 'nullptr' although the compiler supports it already, there
    are good chances that there will be no compilation error. (That's what
    I observed with all compilers except GCC.)
Therefore I did not want to make bets regarding C++ compilers that set
__cplusplus = 201103L but that I have not tested.

Bruno





^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: module c-nullptr: error compiling groff
  2023-02-06  5:10   ` Paul Eggert
  2023-02-06 11:13     ` Bruno Haible
@ 2023-02-07 21:50     ` Bruno Haible
  1 sibling, 0 replies; 5+ messages in thread
From: Bruno Haible @ 2023-02-07 21:50 UTC (permalink / raw)
  To: bug-gnulib, Paul Eggert; +Cc: Bjarni Ingi Gislason

Paul Eggert wrote:
> It seems unlikely that a compiler would 
> advertise conformance to C++11 without supporting nullptr.

Here's a case where a compiler advertises conformance to C++11 without
supporting all that's needed:
https://bugs.llvm.org/show_bug.cgi?id=44871

I'm sure there are more examples like this.

Bruno





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-02-07 21:51 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-06  0:22 module c-nullptr: error compiling groff Bjarni Ingi Gislason
2023-02-06  3:27 ` Bruno Haible
2023-02-06  5:10   ` Paul Eggert
2023-02-06 11:13     ` Bruno Haible
2023-02-07 21:50     ` Bruno Haible

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).