Re: CFT: snmalloc as libc malloc (the nullptr_t issue)

Looks to me like FreeBSD's problem: there is a rule about <stddef.h>
inclusion leading to a definition of nullptr_t that is not being
followed. The details follow.

The complaint:

/usr/obj/data/src/hardenedbsd/amd64.amd64/tmp/usr/include/c++/v1/cstddef:50:9: error: no member named 'nullptr_t' in the global namespace
using ::nullptr_t;

is reported against text in FreeBSD's usr/include/c++/v1/cstddef
(so against the llvm15 integration).

cppreference.com <http://cppreference.com/> reports for nullptr_t :

. . .
Defined in header <cstddef>
using nullptr_t = decltype(nullptr);

Notes
nullptr_t is available in the global namespace when <stddef.h> is included, even if it is not a part of C99~C17 (referenced by C++11~C++20).
nullptr_t is also a part of C since C23.
. . .

c++/v1/cstddef has, in part:

. . .
#include <stddef.h>
#include <version>

#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
#  pragma GCC system_header
#endif

_LIBCPP_BEGIN_NAMESPACE_STD

using ::nullptr_t;
. . .

But, in FreeBSD, <stddef.h> directly and indirectly does not lead to
a nullptr_t definition as far as I could find.

===
Mark Millard
marklmi at yahoo.com