There was no space in ((void *)0) before D158709. This can cause
downstream warnings in case other libraries define NULL as
((void*)0), which is the case for musl. (see NULL definition in
https://git.musl-libc.org/cgit/musl/tree/include/stdio.h)
When a macro is redefined, if the content is the same it is fine, but if
it is different even in terms of a single space, clang warns:
../musl/include/stdio.h:37:9: error: 'NULL' macro redefined [-Werror,-Wmacro-redefined] 37 | #define NULL ((void*)0) | ^
The old code didn't have the space and it had been fine for many years,
so I think there's no risk in removing it. The linter seems to prefer
the space in there, but I think it has a risk of causing warnings or
even errors for downstream users.
My concern with this comment is that it implies we can never change our definition of NULL -- as the implementation, this is ours to define and if other C standard libraries (also part of the implementation!) are redefining the macro, IMO, they need to solve this themselves with either #ifdef or #undef as needed instead of expecting the definitions to stay in lock-step including whitespace. I don't expect us to change the definition of NULL any time soon, but this feels like a bad precedent to set. I'm not opposed (this is solving a real problem), but I'm wondering if musl would consider guarding their macro definitions so we don't have this fragility forever? We need to keep it for now so existing musl uses don't have this problem, but I don't really want to make the guarantees this comment is claiming.