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.
