Re: Gnulib and nullptr

[Bruno Haible]

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