Gnulib and nullptr

Gnulib and nullptr

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

To support an approximation to C23's nullptr keyword I installed the 
attached patch into Gnulib. To test it a bit I'm using the new c-nullptr 
module in GNU diffutils, by preferring nullptr to NULL in the diffutils 
source. See:

https://git.savannah.gnu.org/cgit/diffutils.git/commit/?id=09f8e2b0a92f3d25325f5b1df20384140261ee10

Assuming this works out, at some point I would like to change Gnulib 
itself to prefer nullptr to NULL, due to nullptr's somewhat-better 
properties. There's no rush of course.

With current c-nullptr Gnulib .h files would continue to use NULL rather 
than nullptr, since we couldn't assume client code includes a <config.h> 
that defines nullptr on pre-C23 platforms, so perhaps at some point that 
could be improved as well.

[-- Attachment #2: 0001-c-nullptr-new-module.patch --]
[-- Type: text/x-patch, Size: 5097 bytes --]

From 28c79f93121923acb8cc77270a63701ed4926846 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 5 Feb 2023 09:47:12 -0800
Subject: [PATCH] c-nullptr: new module

* doc/gnulib.texi (nullptr): New section.
* doc/posix-headers/stddef.texi: Document lack of nullptr_t.
* m4/c-nullptr.m4, modules/c-nullptr: New files.
---
 ChangeLog                     |  7 ++++++
 doc/gnulib.texi               | 42 +++++++++++++++++++++++++++++++++++
 doc/posix-headers/stddef.texi |  6 +++++
 m4/c-nullptr.m4               | 30 +++++++++++++++++++++++++
 modules/c-nullptr             | 20 +++++++++++++++++
 5 files changed, 105 insertions(+)
 create mode 100644 m4/c-nullptr.m4
 create mode 100644 modules/c-nullptr

diff --git a/ChangeLog b/ChangeLog
index 3cc97a8c34..51a731f115 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2023-02-05  Paul Eggert  <eggert@cs.ucla.edu>
+
+	c-nullptr: new module
+	* doc/gnulib.texi (nullptr): New section.
+	* doc/posix-headers/stddef.texi: Document lack of nullptr_t.
+	* m4/c-nullptr.m4, modules/c-nullptr: New files.
+
 2023-02-05  Bruno Haible  <bruno@clisp.org>
 
 	Update build-aux/po/Makefile.in.in.
diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index e9a4ace67f..b3f011818c 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -867,6 +867,7 @@ substituted by Gnulib.
 @menu
 * alignof::        @code{alignas} and @code{alignof}
 * bool::           @code{bool}, @code{false}, and @code{true}
+* nullptr::        @code{nullptr}
 * static_assert::  @code{static_assert}
 @end menu
 
@@ -916,6 +917,47 @@ On pre-C23 platforms, the keyword substitutes are macros.
 On pre-C23 platforms, the keyword substitutes assume C99 or later.
 @end itemize
 
+@node nullptr
+@section @code{nullptr}
+
+Gnulib module: c-nullptr
+
+@cindex null pointer
+The @code{c-nullptr} module arranges for @code{nullptr} to act
+like standard C@.
+
+The C @code{nullptr} keyword yields a null pointer.  It differs from
+the @code{NULL} macro, in that @code{NULL} might be an integer whereas
+@code{nullptr} is of a special @code{nullptr_t} type with only one
+value, namely @code{nullptr} itself.  Using @code{nullptr} can help
+some compilers emit more sensible warnings, can avoid the need to cast
+a null pointer passed to a function prototyped with an ellipsis, and
+removes the need to include @code{<stddef.h>} merely to define
+@code{NULL}.
+
+Portability problems fixed by Gnulib:
+@itemize
+@item
+Some platforms lack @code{nullptr}:
+GCC 12, Clang 15, and other pre-2023 C compilers.
+@end itemize
+
+Portability problems not fixed by Gnulib:
+@itemize
+@item
+On older platforms, @code{nullptr} is a macro instead of a keyword.
+
+@item
+On older platforms, @code{nullptr} does not have the type @code{nullptr_t}.
+In C, it has type @code{void *}; in C++ it has an integer type.
+
+@item
+On older platforms Gnulib cannot easily emulate @code{nullptr_t}, so
+null pointer type checking is more error prone, and @code{_Generic}
+expressions cannot reliably distinguish @code{nullptr}'s type from
+integer or @code{void *} types.
+@end itemize
+
 @node static_assert
 @section @code{static_assert}
 
diff --git a/doc/posix-headers/stddef.texi b/doc/posix-headers/stddef.texi
index fe7ed26c9b..e240f93363 100644
--- a/doc/posix-headers/stddef.texi
+++ b/doc/posix-headers/stddef.texi
@@ -35,6 +35,12 @@ it does not fulfil the expectations of other system header files.
 
 Portability problems not fixed by Gnulib:
 @itemize
+@item
+@cindex null pointer type
+Some platforms fail to provide @code{nullptr_t},
+which Gnulib cannot usefully emulate:
+GCC 12, Clang 15, and other pre-2023 C compilers.
+
 @item
 Some platforms provide an @code{offsetof} macro that cannot be used in
 arbitrary expressions:
diff --git a/m4/c-nullptr.m4 b/m4/c-nullptr.m4
new file mode 100644
index 0000000000..af79854696
--- /dev/null
+++ b/m4/c-nullptr.m4
@@ -0,0 +1,30 @@
+# Check for nullptr that conforms to C23.
+
+dnl Copyright 2023 Free Software Foundation, Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+AC_DEFUN([gl_C_NULLPTR],
+[
+  AC_CACHE_CHECK([for nullptr], [gl_cv_c_nullptr],
+    [AC_COMPILE_IFELSE(
+       [AC_LANG_SOURCE([[int *p = nullptr;]])],
+       [gl_cv_c_nullptr=yes],
+       [gl_cv_c_nullptr=no])])
+  if test "$gl_cv_c_nullptr" = yes; then
+    AC_DEFINE([HAVE_C_NULLPTR], [1], [Define to 1 if nullptr works.])
+  fi
+])
+
+  AH_VERBATIM([nullptr],
+[#ifndef HAVE_C_NULLPTR
+# ifndef __cplusplus
+#  define nullptr ((void *) 0)
+# elif 3 <= __GNUG__
+#  define nullptr __null
+# else
+#  define nullptr 0L
+# endif
+#endif])
+])
diff --git a/modules/c-nullptr b/modules/c-nullptr
new file mode 100644
index 0000000000..bc5fa43200
--- /dev/null
+++ b/modules/c-nullptr
@@ -0,0 +1,20 @@
+Description:
+A nullptr that is like C23.
+
+Files:
+m4/c-nullptr.m4
+
+Depends-on:
+
+configure.ac:
+gl_C_NULLPTR
+
+Makefile.am:
+
+Include:
+
+License:
+LGPLv2+
+
+Maintainer:
+all
-- 
2.37.2

Re: Gnulib and nullptr

[Bruno Haible]

[-- Attachment #1: Type: text/plain, Size: 2884 bytes --]

Paul Eggert wrote:
> To support an approximation to C23's nullptr keyword I installed the 
> attached patch into Gnulib.

Thanks for that.

> at some point I would like to change Gnulib 
> itself to prefer nullptr to NULL, due to nullptr's somewhat-better 
> properties. There's no rush of course.

Not so quickly, please.

1) I'm not convinced of the "somewhat-better properties" of nullptr compared
to NULL. In the C23 standard, there is no rationale. Reading the rationale
section in
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm#rationale
I only see arguments that are hardly relevant for Gnulib:

- "If NULL has integer type ... and varargs"
  Old platforms had '#define NULL 0'. But now that most platforms have added
  support for a 64-bit mode, such problems have been mostly corrected.
  Here are the definitions of NULL in C mode:
    - gcc, clang, *BSD, macOS, MSVC: ((void*)0)
    - Solaris 10/11 cc 32-bit: 0
    - Solaris 10/11 cc 64-bit: 0L
    - AIX xlc: 0
  So this is all only for Solaris cc and AIX xlc.
  The diffutils patch shows that the possible bugs had already been caught by
  writing  (char *) NULL  instead of  NULL.

- char* a = va_arg(ap, char*);
  The last platform in which pointers and integers were passed differently
  as function arguments were m68k machines, around 1990.

- "confusion between a null pointer and a pointer that points to the zero
   address in the OS"
  On which OSes is a NULL pointer not the same as a pointer with value
  (uintptr_t)0 ?

The only argument in favour of 'nullptr' in C that I see is that it has some
use in C++, when it comes to overloading resolution (cf.
https://stackoverflow.com/questions/1282295/), and it is useful to have
similar coding styles in C as in C++.

2) We should avoid gratuitous style differences between code in Gnulib and
general coding habits in the community, because that increases the barrier
to entry and confuses newcomers. We already have to teach newcomers a number
of things:
  - how to submit a code change as a patch,
  - to use GNU coding style,
  - Gnulib conventions (e.g. to use spaces for intentation),
and these are all practically relevant. I don't wish to add to this list
some style differences that are not actually relevant.

3) There are practical impediments now: In a current (Ubuntu 22.04) distro,
both Emacs and vim don't know about 'nullptr' in the same way as about 'NULL'.
When they apply syntax-colouring to a program, 'nullptr' is shown like a
random identifier. See the attached screenshots.


Therefore, I would be in favour of EITHER
* doing this when the community as a whole has adopted 'nullptr' in C, i.e.
  this keyword is no longer something that is new to an average newcomer,
  (even if that's only 10 years from now),
OR
* doing the change only in those places where it actually matters, that is,
  in varargs argument lists.

Bruno


[-- Attachment #2: nullptr-in-emacs.png --]
[-- Type: image/png, Size: 7681 bytes --]

[-- Attachment #3: nullptr-in-vim.png --]
[-- Type: image/png, Size: 6034 bytes --]

Re: Gnulib and nullptr

[Bruno Haible]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

Paul Eggert wrote:
> Assuming this works out, ...

Bjarni's report
<https://lists.gnu.org/archive/html/bug-gnulib/2023-02/msg00030.html>
indicates that we need unit tests for this module.


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

	c-nullptr: Add tests.
	* tests/test-nullptr.c: New file.
	* modules/c-nullptr-tests: New file.
	* tests/test-nullptr-c++.cc: New file.
	* modules/c-nullptr-c++-tests: New file.


[-- Attachment #2: 0001-c-nullptr-Add-tests.patch --]
[-- Type: text/x-patch, Size: 5396 bytes --]

From 9922eb1b1d665ee68dd1811813818b8fde43a3d9 Mon Sep 17 00:00:00 2001
From: Bruno Haible <bruno@clisp.org>
Date: Mon, 6 Feb 2023 02:55:47 +0100
Subject: [PATCH] c-nullptr: Add tests.

* tests/test-nullptr.c: New file.
* modules/c-nullptr-tests: New file.
* tests/test-nullptr-c++.cc: New file.
* modules/c-nullptr-c++-tests: New file.
---
 ChangeLog                   |  8 +++++
 modules/c-nullptr-c++-tests | 17 +++++++++
 modules/c-nullptr-tests     | 12 +++++++
 tests/test-nullptr-c++.cc   | 57 ++++++++++++++++++++++++++++++
 tests/test-nullptr.c        | 69 +++++++++++++++++++++++++++++++++++++
 5 files changed, 163 insertions(+)
 create mode 100644 modules/c-nullptr-c++-tests
 create mode 100644 modules/c-nullptr-tests
 create mode 100644 tests/test-nullptr-c++.cc
 create mode 100644 tests/test-nullptr.c

diff --git a/ChangeLog b/ChangeLog
index a28f407288..4c9bff951b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2023-02-05  Bruno Haible  <bruno@clisp.org>
+
+	c-nullptr: Add tests.
+	* tests/test-nullptr.c: New file.
+	* modules/c-nullptr-tests: New file.
+	* tests/test-nullptr-c++.cc: New file.
+	* modules/c-nullptr-c++-tests: New file.
+
 2023-02-05  Paul Eggert  <eggert@cs.ucla.edu>
 
 	sh-quote: backport fix from diffutils
diff --git a/modules/c-nullptr-c++-tests b/modules/c-nullptr-c++-tests
new file mode 100644
index 0000000000..ae60f4b360
--- /dev/null
+++ b/modules/c-nullptr-c++-tests
@@ -0,0 +1,17 @@
+Files:
+tests/test-nullptr-c++.cc
+
+Status:
+c++-test
+
+Depends-on:
+ansi-c++-opt
+
+configure.ac:
+
+Makefile.am:
+if ANSICXX
+TESTS += test-nullptr-c++
+check_PROGRAMS += test-nullptr-c++
+test_nullptr_c___SOURCES = test-nullptr-c++.cc
+endif
diff --git a/modules/c-nullptr-tests b/modules/c-nullptr-tests
new file mode 100644
index 0000000000..40e28d200b
--- /dev/null
+++ b/modules/c-nullptr-tests
@@ -0,0 +1,12 @@
+Files:
+tests/test-nullptr.c
+tests/macros.h
+
+Depends-on:
+c-nullptr-c++-tests
+
+configure.ac:
+
+Makefile.am:
+TESTS += test-nullptr
+check_PROGRAMS += test-nullptr
diff --git a/tests/test-nullptr-c++.cc b/tests/test-nullptr-c++.cc
new file mode 100644
index 0000000000..fdcfd04356
--- /dev/null
+++ b/tests/test-nullptr-c++.cc
@@ -0,0 +1,57 @@
+/* Test nullptr in C++ mode.
+   Copyright 2023 Free Software Foundation, Inc.
+
+   This program is free software: you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation, either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <https://www.gnu.org/licenses/>.  */
+
+/* Written by Bruno Haible.  */
+
+#include <config.h>
+
+/* Check that nullptr is defined.  */
+int *my_null = nullptr;
+
+/* Check against conflicts between <config.h> and the C++ header files.  */
+#include <iostream>
+#include <vector>
+
+#include <stdarg.h>
+
+#include "macros.h"
+
+void
+varargs_callee (const char *first, ...)
+{
+  va_list args;
+  const char *arg;
+
+  ASSERT (first[0] == 't');
+  va_start (args, first);
+
+  arg = va_arg (args, const char *);
+  ASSERT (arg == NULL);
+
+  arg = va_arg (args, const char *);
+  ASSERT (arg[0] == 'f');
+
+  arg = va_arg (args, const char *);
+  ASSERT (arg == NULL);
+
+  va_end (args);
+}
+
+int
+main ()
+{
+  varargs_callee ("type", nullptr, "foo", nullptr);
+}
diff --git a/tests/test-nullptr.c b/tests/test-nullptr.c
new file mode 100644
index 0000000000..1f9abc7422
--- /dev/null
+++ b/tests/test-nullptr.c
@@ -0,0 +1,69 @@
+/* Test nullptr.
+   Copyright 2023 Free Software Foundation, Inc.
+
+   This program is free software: you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation, either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <https://www.gnu.org/licenses/>.  */
+
+/* Written by Bruno Haible.  */
+
+#include <config.h>
+
+int *my_null = nullptr;
+
+#if 0 /* not yet */
+/* Header that is supposed to define nullptr_t.  */
+# include <stddef.h>
+#endif
+
+#include <stdarg.h>
+
+#include "macros.h"
+
+#if 0 /* not yet */
+
+static void
+simple_callee (nullptr_t x)
+{
+  ASSERT (x == NULL);
+}
+
+#endif
+
+void
+varargs_callee (const char *first, ...)
+{
+  va_list args;
+  const char *arg;
+
+  ASSERT (first[0] == 't');
+  va_start (args, first);
+
+  arg = va_arg (args, const char *);
+  ASSERT (arg == NULL);
+
+  arg = va_arg (args, const char *);
+  ASSERT (arg[0] == 'f');
+
+  arg = va_arg (args, const char *);
+  ASSERT (arg == NULL);
+
+  va_end (args);
+}
+
+int
+main ()
+{
+  varargs_callee ("type", nullptr, "foo", nullptr);
+
+  return 0;
+}
-- 
2.34.1

Re: Gnulib and nullptr

[Bruno Haible]

Paul Eggert wrote:
> the new c-nullptr module

Why call it 'c-nullptr', not 'nullptr'?

Re: Gnulib and nullptr

[Paul Eggert]

On 2023-02-05 18:00, Bruno Haible wrote:
> Why call it 'c-nullptr', not 'nullptr'?

I was worried about C++, not that I know much about it, and operated by 
analogy with the name of m4/c-bool.m4. If 'nullptr' is a better name 
then let's switch to it. I assume we'd also switch the file names, the 
macro names, etc.

Re: Gnulib and nullptr

[Simon Josefsson via Gnulib discussion list]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Bruno Haible <bruno@clisp.org> writes:

> Therefore, I would be in favour of EITHER
> * doing this when the community as a whole has adopted 'nullptr' in C, i.e.
>   this keyword is no longer something that is new to an average newcomer,
>   (even if that's only 10 years from now),
> OR
> * doing the change only in those places where it actually matters, that is,
>   in varargs argument lists.

I agree with this conclucsion -- and pending 1) above, I believe 2) is
sufficient and I would argue that we should all generally continue to
use NULL in all other cases than varargs because it is a well-known
idiom.  This may cause 1) above to never occur, which seems acceptable.
This assumes there aren't other important use-cases for nullptr than
varargs that aren't clear.  Personally I don't believe consistency with
C++ is important (usually this makes C code uglier and less idiomatic in
my experience) but opinion may vary.

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Gnulib and nullptr

[Bruno Haible]

Paul Eggert wrote:
> > Why call it 'c-nullptr', not 'nullptr'?
> 
> I was worried about C++, not that I know much about it, and operated by 
> analogy with the name of m4/c-bool.m4.

OK, I see. So the prefix 'c-' in 'c-bool' and 'c-nullptr' means something
like "ISO C standard compliant". We could also have been using a prefix
'std-' maybe. Anyway, it's OK; it just wasn't immediately clear to me.

Bruno

Re: Gnulib and nullptr

[Paul Eggert]

On 2/5/23 16:57, Bruno Haible wrote:

>   The diffutils patch shows that the possible bugs had already been caught

Sure, but the idea is to make such bugs less likely in the future, by 
encouraging the use of nullptr now.

>   The last platform in which pointers and integers were passed differently
>   as function arguments were m68k machines, around 1990.

As I understand it they can still be passed differently in IBM i 7.5, 
released 2022-05-10, and I expect (though I haven't checked) that some 
of that platform's null pointer representations are not all bits zero.
Of course this is not one of Gnulib's supported targets.


> The only argument in favour of 'nullptr' in C that I see is that it has some
> use in C++

It's not just avoiding varargs bug (which is an advantage on some 
platforms). Also, erroneous code like this:

    #if _AIX || __HAIKU__
      exit (i < j ? j - i : nullptr);
    #endif

will be caught at compile-time on AIX with a proper nullptr, whereas if 
the code uses NULL instead of nullptr we won't get diagnostics until we 
compile on Haiku as well. Although a contrived example, this sort of 
thing can be an advantage when compiling code intended for these 
rarely-used platforms.


> 2) We should avoid gratuitous style differences between code in Gnulib and
> general coding habits in the community, because that increases the barrier
> to entry and confuses newcomers.

This barrier is so small as to not be worth worrying about. People 
accustomed to NULL can still submit patches containing NULL, and we can 
accept them. And readers won't be significantly confused by seeing the 
newer "nullptr" style in the code, or by seeing it highlighted 
incorrectly by older Emacs.

NULL is a tricky anachronism. I'm willing to switch to nullptr 
downstream and be the guinea pig, if you'd rather have Gnulib be 
cautious about this. But there seems little reason to hang on to NULL 
indefinitely.

Re: Gnulib and nullptr

[Jeffrey Walton]

On Sun, Feb 5, 2023 at 9:45 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 2023-02-05 18:00, Bruno Haible wrote:
> > Why call it 'c-nullptr', not 'nullptr'?
>
> I was worried about C++, not that I know much about it, and operated by
> analogy with the name of m4/c-bool.m4. If 'nullptr' is a better name
> then let's switch to it. I assume we'd also switch the file names, the
> macro names, etc.

In C++, nullptr is not convertible to an integral. So this no longer
causes confusion:

    g(void*);
    g(int);

g(nullptr) will always match g(void*). g(int) will never be matched,
which could happen with g(NULL).

Jeff

Re: Gnulib and nullptr

[Dmitrii Pasechnik]

On Mon, Feb 06, 2023 at 04:22:46PM -0500, Jeffrey Walton wrote:
> On Sun, Feb 5, 2023 at 9:45 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> >
> > On 2023-02-05 18:00, Bruno Haible wrote:
> > > Why call it 'c-nullptr', not 'nullptr'?
> >
> > I was worried about C++, not that I know much about it, and operated by
> > analogy with the name of m4/c-bool.m4. If 'nullptr' is a better name
> > then let's switch to it. I assume we'd also switch the file names, the
> > macro names, etc.
> 
> In C++, nullptr is not convertible to an integral. So this no longer
> causes confusion:
> 
>     g(void*);
>     g(int);
> 
> g(nullptr) will always match g(void*). g(int) will never be matched,
> which could happen with g(NULL).

As compilers C++ compilers get stricter, more and more old C++ code
breaks due to NULL being of wrong type. I did quite a bit of patching
of such code replacing NULL with nullptr in the last few years.

Dima

Re: Gnulib and nullptr

[Bruno Haible]

Paul Eggert wrote:
> >   The diffutils patch shows that the possible bugs had already been caught
> 
> Sure, but the idea is to make such bugs less likely in the future, by 
> encouraging the use of nullptr now.

The gain here is small (it's only varargs and contrived cases), whereas ...

> > 2) We should avoid gratuitous style differences between code in Gnulib and
> > general coding habits in the community, because that increases the barrier
> > to entry and confuses newcomers.
> 
> This barrier is so small as to not be worth worrying about.

I disagree here. Ignoring or underestimating the "barrier to entry" issue
was my biggest mistake in GNU clisp development so far. Even such simple
things tend to turn contributors off.

> People 
> accustomed to NULL can still submit patches containing NULL, and we can 
> accept them.

This would be even worse, because it would lead to a random mix of code
with NULL and code with nullptr. Each time programmers have the choice
between two equivalent ways of coding something, it has three negative
effects:
  * They spend time reflecting whether they should use one or the other.
    Since the two are equivalent, this is wasted time.
  * They get attached to doing it one way, developing a personal style.
    And then they change past contributions by other developers, because
    they get annoyed or even angry about the other style.
  * When searching for some code by pattern or idiom, a developer may
    need two 'grep' runs instead of one.

We've seen this happen
  - with the indentation width and braces style, before the GCS were
    invented,
  - with spaces indentation vs. mixed tab/spaces indentation,
  - in Common Lisp, with SETQ vs. SETF,
  - in C++, with many other constructs. Last time I counted, there were
    12 different ways to define a function in C++. And the programmers
    spend a lot of time deliberating which of them to choose in each
    particular situation. What a waste of time!

Thus, it is better to have a rule (at least per project). Any of the
two rules
  - "Avoid NULL, write nullptr always."
  - "In varargs calls, write nullptr instead of  (foo *) NULL."
is better than a random mix of NULL and nullptr in the same project.

Bruno

Re: Gnulib and nullptr

[Paul Eggert]

On 2/6/23 15:16, Bruno Haible wrote:

> Ignoring or underestimating the "barrier to entry" issue
> was my biggest mistake in GNU clisp development so far.

Fair enough, but surely there are differences between the clisp and 
Gnulib cases. In C++ there are more advantages to nullptr (so more of a 
pressure to use it) than in C. As C++ is popular, many potential 
contributors will be used to nullptr being better; for these people, 
using NULL will be a barrier to entry.

> Thus, it is better to have a rule (at least per project). Any of the
> two rules
>    - "Avoid NULL, write nullptr always."
>    - "In varargs calls, write nullptr instead of  (foo *) NULL."
> is better than a random mix of NULL and nullptr in the same project.

In diffutils proper I switched to the former rule (though code imported 
from Gnulib still uses NULL so people that build from tarballs will 
still see a mixture). I plan to try things out this way for a while, to 
see whether there are problems with the Gnulib nullptr implementation. 
We can convert more intensely-maintained projects later, depending on 
diffutils goes.

A couple of other things.

1. Since the nullptr issue affects C++ so much (something I wasn't aware 
of until now), I'm inclined to rename the module from c-nullptr to 
nullptr as was hinted earlier. It's not just C so the "c-" is a bit 
misleading.

2. The issues you mentioned about C++ compilers possibly not supporting 
nullptr seem to be serious enough that it seems that we should test the 
C++ compiler at configure time, as we already test the C compiler. That 
way we wouldn't have to worry whether our __cplusplus-related #ifdefs 
are OK.

Re: Gnulib and nullptr

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On 2/6/23 18:30, Paul Eggert wrote:
> 1. Since the nullptr issue affects C++ so much (something I wasn't aware 
> of until now), I'm inclined to rename the module from c-nullptr to 
> nullptr as was hinted earlier. It's not just C so the "c-" is a bit 
> misleading.
> 
> 2. The issues you mentioned about C++ compilers possibly not supporting 
> nullptr seem to be serious enough that it seems that we should test the 
> C++ compiler at configure time, as we already test the C compiler. That 
> way we wouldn't have to worry whether our __cplusplus-related #ifdefs 
> are OK.

I installed the attached to try to address these issues. The third patch 
fixes some problems I ran into when using the first two on diffutils and 
groff. I pushed the diffutils change onto Savannah (but not groff of 
course). Comments welcome, as quite possibly there are further 
opportunities for improvement.

[-- Attachment #2: 0001-nullptr-rename-from-c-nullptr.patch --]
[-- Type: text/x-patch, Size: 4874 bytes --]

From 96d3aaacc5aaa0e325eff344dd7ae0e0fbf4b418 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 7 Feb 2023 14:30:54 -0800
Subject: [PATCH 1/3] nullptr: rename from c-nullptr

* NEWS, doc/gnulib.texi: Mention this.
* m4/nullptr.m4: Rename from m4/c-nullptr.m4.
(gl_NULLPTR): Rename from gl_C_NULLPTR.
* modules/nullptr: Rename from modules/nullptr.
* modules/nullptr-c++-tests: Rename from modules/c-nullptr-c++-tests.
* modules/nullptr-tests: Rename from modules/c-nullptr-tests.
All uses changed.
---
 ChangeLog                                          | 11 +++++++++++
 NEWS                                               |  2 ++
 doc/gnulib.texi                                    | 11 ++++++-----
 m4/{c-nullptr.m4 => nullptr.m4}                    |  2 +-
 modules/{c-nullptr => nullptr}                     |  4 ++--
 modules/{c-nullptr-c++-tests => nullptr-c++-tests} |  0
 modules/{c-nullptr-tests => nullptr-tests}         |  2 +-
 7 files changed, 23 insertions(+), 9 deletions(-)
 rename m4/{c-nullptr.m4 => nullptr.m4} (98%)
 rename modules/{c-nullptr => nullptr} (82%)
 rename modules/{c-nullptr-c++-tests => nullptr-c++-tests} (100%)
 rename modules/{c-nullptr-tests => nullptr-tests} (87%)

diff --git a/ChangeLog b/ChangeLog
index b6eec570be..defcef16e3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2023-02-07  Paul Eggert  <eggert@cs.ucla.edu>
+
+	nullptr: rename from c-nullptr
+	* NEWS, doc/gnulib.texi: Mention this.
+	* m4/nullptr.m4: Rename from m4/c-nullptr.m4.
+	(gl_NULLPTR): Rename from gl_C_NULLPTR.
+	* modules/nullptr: Rename from modules/nullptr.
+	* modules/nullptr-c++-tests: Rename from modules/c-nullptr-c++-tests.
+	* modules/nullptr-tests: Rename from modules/c-nullptr-tests.
+	All uses changed.
+
 2023-02-07  Bruno Haible  <bruno@clisp.org>
 
 	Fix a copyright header - module license mismatch.
diff --git a/NEWS b/NEWS
index f3b508f950..0ec377915c 100644
--- a/NEWS
+++ b/NEWS
@@ -74,6 +74,8 @@ User visible incompatible changes
 
 Date        Modules         Changes
 
+2023-02-07  c-nullptr       Rename this module to nullptr.
+
 2023-01-21  getprogname     The include file is changed from "getprogname.h"
                             to <stdlib.h>.
 
diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index b3f011818c..6fe2678834 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -920,13 +920,13 @@ On pre-C23 platforms, the keyword substitutes assume C99 or later.
 @node nullptr
 @section @code{nullptr}
 
-Gnulib module: c-nullptr
+Gnulib module: nullptr
 
 @cindex null pointer
-The @code{c-nullptr} module arranges for @code{nullptr} to act
-like standard C@.
+The @code{nullptr} module arranges for @code{nullptr} to act
+like standard C and C++.
 
-The C @code{nullptr} keyword yields a null pointer.  It differs from
+The @code{nullptr} keyword yields a null pointer.  It differs from
 the @code{NULL} macro, in that @code{NULL} might be an integer whereas
 @code{nullptr} is of a special @code{nullptr_t} type with only one
 value, namely @code{nullptr} itself.  Using @code{nullptr} can help
@@ -939,7 +939,8 @@ Portability problems fixed by Gnulib:
 @itemize
 @item
 Some platforms lack @code{nullptr}:
-GCC 12, Clang 15, and other pre-2023 C compilers.
+For C: GCC 12, Clang 15, and other pre-2023 C compilers.
+For C++: pre-2011 C++ compilers.
 @end itemize
 
 Portability problems not fixed by Gnulib:
diff --git a/m4/c-nullptr.m4 b/m4/nullptr.m4
similarity index 98%
rename from m4/c-nullptr.m4
rename to m4/nullptr.m4
index 960eeff18d..e1218ccd49 100644
--- a/m4/c-nullptr.m4
+++ b/m4/nullptr.m4
@@ -5,7 +5,7 @@ dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
 dnl with or without modifications, as long as this notice is preserved.
 
-AC_DEFUN([gl_C_NULLPTR],
+AC_DEFUN([gl_NULLPTR],
 [
   AC_CACHE_CHECK([for nullptr], [gl_cv_c_nullptr],
     [AC_COMPILE_IFELSE(
diff --git a/modules/c-nullptr b/modules/nullptr
similarity index 82%
rename from modules/c-nullptr
rename to modules/nullptr
index bc5fa43200..41330854b9 100644
--- a/modules/c-nullptr
+++ b/modules/nullptr
@@ -2,12 +2,12 @@ Description:
 A nullptr that is like C23.
 
 Files:
-m4/c-nullptr.m4
+m4/nullptr.m4
 
 Depends-on:
 
 configure.ac:
-gl_C_NULLPTR
+gl_NULLPTR
 
 Makefile.am:
 
diff --git a/modules/c-nullptr-c++-tests b/modules/nullptr-c++-tests
similarity index 100%
rename from modules/c-nullptr-c++-tests
rename to modules/nullptr-c++-tests
diff --git a/modules/c-nullptr-tests b/modules/nullptr-tests
similarity index 87%
rename from modules/c-nullptr-tests
rename to modules/nullptr-tests
index 40e28d200b..21a7caf00d 100644
--- a/modules/c-nullptr-tests
+++ b/modules/nullptr-tests
@@ -3,7 +3,7 @@ tests/test-nullptr.c
 tests/macros.h
 
 Depends-on:
-c-nullptr-c++-tests
+nullptr-c++-tests
 
 configure.ac:
 
-- 
2.39.1


[-- Attachment #3: 0002-nullptr-test-for-C-nullptr-at-configure-time.patch --]
[-- Type: text/x-patch, Size: 3517 bytes --]

From 7a5061a0527b9fcaeedf48e8f5056dd80e77aa98 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 7 Feb 2023 15:11:32 -0800
Subject: [PATCH 2/3] nullptr: test for C++ nullptr at configure-time

* m4/nullptr.m4 (gl_NULLPTR): Test for C++ support for nullptr
at configure-time, as we already do for C support.
This should be more reliable than maintaining #ifdefs by hand.
---
 ChangeLog     |  5 +++++
 m4/nullptr.m4 | 48 ++++++++++++++++++++++++------------------------
 2 files changed, 29 insertions(+), 24 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index defcef16e3..624afb7e95 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2023-02-07  Paul Eggert  <eggert@cs.ucla.edu>
 
+	nullptr: test for C++ nullptr at configure-time
+	* m4/nullptr.m4 (gl_NULLPTR): Test for C++ support for nullptr
+	at configure-time, as we already do for C support.
+	This should be more reliable than maintaining #ifdefs by hand.
+
 	nullptr: rename from c-nullptr
 	* NEWS, doc/gnulib.texi: Mention this.
 	* m4/nullptr.m4: Rename from m4/c-nullptr.m4.
diff --git a/m4/nullptr.m4 b/m4/nullptr.m4
index e1218ccd49..dda7646906 100644
--- a/m4/nullptr.m4
+++ b/m4/nullptr.m4
@@ -1,4 +1,4 @@
-# Check for nullptr that conforms to C23.
+# Check for nullptr that conforms to C23 and C++11.
 
 dnl Copyright 2023 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
@@ -7,35 +7,35 @@ dnl with or without modifications, as long as this notice is preserved.
 
 AC_DEFUN([gl_NULLPTR],
 [
-  AC_CACHE_CHECK([for nullptr], [gl_cv_c_nullptr],
-    [AC_COMPILE_IFELSE(
-       [AC_LANG_SOURCE([[int *p = nullptr;]])],
-       [gl_cv_c_nullptr=yes],
-       [gl_cv_c_nullptr=no])])
+  AS_IF([test ${CC+set}],
+    [AC_CACHE_CHECK([for C nullptr], [gl_cv_c_nullptr],
+       [AC_COMPILE_IFELSE(
+          [AC_LANG_SOURCE([[int *p = nullptr;]])],
+          [gl_cv_c_nullptr=yes],
+          [gl_cv_c_nullptr=no])])])
   if test "$gl_cv_c_nullptr" = yes; then
-    AC_DEFINE([HAVE_C_NULLPTR], [1], [Define to 1 if nullptr works.])
+    AC_DEFINE([HAVE_C_NULLPTR], [1], [Define to 1 if C nullptr works.])
+  fi
+  AS_IF([test ${CXX+set}],
+    [AC_CACHE_CHECK([for C++ nullptr], [gl_cv_cxx_nullptr],
+       [AC_COMPILE_IFELSE(
+          [AC_LANG_SOURCE([[int *p = nullptr;]])],
+          [gl_cv_cxx_nullptr=yes],
+          [gl_cv_cxx_nullptr=no])])])
+  if test "$gl_cv_cxx_nullptr" = yes; then
+    AC_DEFINE([HAVE_CXX_NULLPTR], [1], [Define to 1 if C++ nullptr works.])
   fi
 ])
 
   AH_VERBATIM([nullptr],
 [#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
-/* For the C compiler, use the result of the configure test.  */
-#  ifndef HAVE_C_NULLPTR
-#   define nullptr ((void *) 0)
+# if !defined __cplusplus && !defined HAVE_C_NULLPTR
+#  define nullptr ((void *) 0)
+# elif defined __cplusplus && !defined HAVE_CXX_NULLPTR
+#  if 3 <= __GNUG__
+#   define nullptr __null
+#  else
+#   define nullptr 0L
 #  endif
 # endif
 #endif])
-- 
2.39.1


[-- Attachment #4: 0003-nullptr-test-for-compilers-at-autoconf-time.patch --]
[-- Type: text/x-patch, Size: 2785 bytes --]

From 97f54920a3c2bd9a536ef8c1cb7667584bd84eaf Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 7 Feb 2023 20:37:09 -0800
Subject: [PATCH 3/3] nullptr: test for compilers at autoconf-time

* m4/nullptr.m4 (gl_NULLPTR): Test for C and C++ compiler usage at
autoconf-time.  This should work better than testing at
configure-time.  Also, push and pop languages so we check the
proper compiler.
---
 ChangeLog     |  6 ++++++
 m4/nullptr.m4 | 28 +++++++++++++++++++---------
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 624afb7e95..09317e6b89 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2023-02-07  Paul Eggert  <eggert@cs.ucla.edu>
 
+	nullptr: test for compilers at autoconf-time
+	* m4/nullptr.m4 (gl_NULLPTR): Test for C and C++ compiler usage at
+	autoconf-time.  This should work better than testing at
+	configure-time.  Also, push and pop languages so we check the
+	proper compiler.
+
 	nullptr: test for C++ nullptr at configure-time
 	* m4/nullptr.m4 (gl_NULLPTR): Test for C++ support for nullptr
 	at configure-time, as we already do for C support.
diff --git a/m4/nullptr.m4 b/m4/nullptr.m4
index dda7646906..a0b438be94 100644
--- a/m4/nullptr.m4
+++ b/m4/nullptr.m4
@@ -7,22 +7,32 @@ dnl with or without modifications, as long as this notice is preserved.
 
 AC_DEFUN([gl_NULLPTR],
 [
-  AS_IF([test ${CC+set}],
-    [AC_CACHE_CHECK([for C nullptr], [gl_cv_c_nullptr],
+  m4_provide_if([AC_PROG_CC],
+    [AC_LANG_PUSH([C])
+     AC_CACHE_CHECK([for C nullptr], [gl_cv_c_nullptr],
        [AC_COMPILE_IFELSE(
           [AC_LANG_SOURCE([[int *p = nullptr;]])],
           [gl_cv_c_nullptr=yes],
-          [gl_cv_c_nullptr=no])])])
-  if test "$gl_cv_c_nullptr" = yes; then
-    AC_DEFINE([HAVE_C_NULLPTR], [1], [Define to 1 if C nullptr works.])
+          [gl_cv_c_nullptr=no])])
+      gl_c_nullptr=$gl_cv_c_nullptr
+      AC_LANG_POP([C])],
+     [gl_c_nullptr=no])
+  if test "$gl_c_nullptr" = yes; then
+    AC_DEFINE([HAVE_C_NULLPTR], [1],
+      [Define to 1 if C nullptr is known to work.])
   fi
-  AS_IF([test ${CXX+set}],
-    [AC_CACHE_CHECK([for C++ nullptr], [gl_cv_cxx_nullptr],
+
+  m4_provide_if([AC_PROG_CXX],
+    [AC_LANG_PUSH([C++])
+     AC_CACHE_CHECK([for C++ nullptr], [gl_cv_cxx_nullptr],
        [AC_COMPILE_IFELSE(
           [AC_LANG_SOURCE([[int *p = nullptr;]])],
           [gl_cv_cxx_nullptr=yes],
-          [gl_cv_cxx_nullptr=no])])])
-  if test "$gl_cv_cxx_nullptr" = yes; then
+          [gl_cv_cxx_nullptr=no])])
+      gl_cxx_nullptr=$gl_cv_cxx_nullptr
+      AC_LANG_POP([C++])],
+     [gl_cxx_nullptr=no])
+  if test "$gl_cxx_nullptr" = yes; then
     AC_DEFINE([HAVE_CXX_NULLPTR], [1], [Define to 1 if C++ nullptr works.])
   fi
 ])
-- 
2.39.1

Re: Gnulib and nullptr

[Bruno Haible]

Paul Eggert wrote:
> +  m4_provide_if([AC_PROG_CC],

Note that m4_provide_if is not documented in the Autoconf manual. Let's hope
it won't change incompatibly...

Bruno

Re: Gnulib and nullptr (and m4_provide_if)

[Paul Eggert]

On 2/8/23 15:15, Bruno Haible wrote:
> m4_provide_if is not documented in the Autoconf manual. Let's hope
> it won't change incompatibly...

Yes, I hope so too. Gnulib is already using m4_provide_if in 
gnulib/m4/largefile.m4 (in code stolen from Autoconf) so to some extent 
we're exposed already, though of course this gnulib/m4/nullptr.m4 change 
increases Gnulib's exposure.

One possibility is for Autoconf to document m4_provide_if and friends, 
since they haven't changed in two decades. I'll cc this email to Akim to 
see whether he has insight as to why the Autoconf manual doesn't 
document m4_provide_if etc. already.

Re: Gnulib and nullptr (and m4_provide_if)

[Akim Demaille]

Hi Friends,

> Le 9 févr. 2023 à 01:42, Paul Eggert <eggert@cs.ucla.edu> a écrit :
> 
> On 2/8/23 15:15, Bruno Haible wrote:
>> m4_provide_if is not documented in the Autoconf manual. Let's hope
>> it won't change incompatibly...
> 
> Yes, I hope so too. Gnulib is already using m4_provide_if in gnulib/m4/largefile.m4 (in code stolen from Autoconf) so to some extent we're exposed already, though of course this gnulib/m4/nullptr.m4 change increases Gnulib's exposure.
> 
> One possibility is for Autoconf to document m4_provide_if and friends, since they haven't changed in two decades. I'll cc this email to Akim to see whether he has insight as to why the Autoconf manual doesn't document m4_provide_if etc. already.

I have absolutely no idea :)  But it seems that m4_provide_if is considered to be part of m4sugar, and AC_PROVIDE_IFELSE to be its alter ego for Autoconf.  Not documented either...

Cheers!