Re: CFT: snmalloc as libc malloc (the nullptr_t issue)
- Reply: Mark Millard : "Re: CFT: snmalloc as libc malloc (the nullptr_t issue)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 10 Feb 2023 20:01:00 UTC
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