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.