[libcxx-commits] [libcxx] [libc++] Simplify the implementation of <stddef.h> (PR #86843)

[Daniel Bertalan via libcxx-commits]

BertalanD wrote:

@ldionne Just a heads-up (already mentioned this on [Discord](https://discord.com/channels/636084430946959380/636732894974312448/1260365229770936391)): this caused GCC to fail to compile with Xcode 16 beta:

```
../../gcc/value-pointer-equiv.cc:65:43: error: no viable conversion from 'pair<typename __unwrap_ref_decay<long>::type, typename __unwrap_ref_decay<long>::type>' to 'const pair<tree, tree>'
   65 |   const std::pair <tree, tree> m_marker = std::make_pair (NULL, NULL);
      |                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

(`tree` here is a typedef to a pointer type)

Apparently what they do is redefine `NULL` to `nullptr` in `gcc/system.h` which is included in every TU of the compiler:
https://github.com/gcc-mirror/gcc/blob/1ae5fc24e86ecc9e7b60346d9ca2e56f83517bda/gcc/system.h#L1296-L1304

This was added in https://github.com/gcc-mirror/gcc/commit/d59a576b8b5e12c3a56f0262912090e2921f5daa to fix an issue similar to mine. This used to work because `gcc/system.h` already includes `stddef.h` further up:

https://github.com/gcc-mirror/gcc/blob/1ae5fc24e86ecc9e7b60346d9ca2e56f83517bda/gcc/system.h#L42-L44

But `stddef.h` might be included later too, such as through `include/obstack.h`. And since the include guards were removed from the `#include_next` in this PR, it changes back the definition of `NULL` to `__null`, leading to the above issue.

I posted a [patch](https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656779.html) for this to the GCC mailing list, but they're asking if this can be fixed on the libc++/macOS SDK side. (Louis, is macOS `stddef.h` overriding `NULL`s value if it's already defined a deliberate decision?)

https://github.com/llvm/llvm-project/pull/86843