Don't define NULL to nullptr in C++11 mode

[jhb]

Summary

While C++ does seem to permit this, both GCC and clang do not do this
in their bundled <stddef.h> headers. Instead, both use the null
builtin (and g++ unconditionally overrides NULL back to null).

Our local change makes FreeBSD's C++ environment subtly different from
the rest of the world such that code that compiles fine with clang++
on FreeBSD doesn't compile fine on other systems and doesn't compile
on FreeBSD using g++.

This reverts commit 3033610f5dfd03b68de35631a8693963a80099c2.

[jhb]

This makes C++ on FreeBSD less of a special snowflake. In particular, once this is reverted, clang fails the same way GCC fails currently on kyua. Had this not been in place, I wouldn't have pushed a broken patchset to kyua. :(

[theraven]

This probably needs an exp run, I don’t know how many ports depend on this behaviour.

[jhb]

In D50089#1142520, @theraven wrote:

This probably needs an exp run, I don’t know how many ports depend on this behaviour.

I can do an exp-run. I expect if anything this would fix more things than it breaks as I'm pretty certain NULL is __null on Linux for both GCC and clang.

[jhb]

exp-run requested at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286477

[olce]

I concur that C++(11+) seems to permit this. I don't know why GCC didn't do the exact thing @theraven did in commit rG3033610f5dfd03 in C++(11+), as it was the most helpful way forward (backwards compatibility?). From readings here and there (but not the source code), it seems their __null actually only ensures an object of size a pointer, but can still be considered an integer in some cases. That also is permitted by C++ (ironically, not considering it an integer sometimes is probably not).

I'd expect close to zero changes in fact, as defining NULL as nullptr is more stringent, and on the other hand, as @jhb said, if __null was a problem the upstreams would have noticed that, e.g., on Linux. But perhaps we have ports tree patches using NULL that are not going to work anymore (causing the same errors as those seen with Kyua). So an exp-run is probably more prudent, FWIW.

[dim]

It's a bit unfortunate, but better to do the same thing as most other systems.

[emaste]

It's a bit unfortunate, but better to do the same thing as most other systems.

Yeah - in fact, maybe we should leave a note that we'd like to #define NULL nullptr but it breaks some software.

[olce]

In D50089#1142581, @dim wrote:

It's a bit unfortunate, but better to do the same thing as most other systems.

If that battle has to be fought, given the FOSS ecosystem, it should likely be so at the GCC project's level.

[jhb]

FWIW, of the two ports that broke, one had already fixed itself upstream but we just have an ancient version in the ports tree.