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
