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.