Date: Fri, 10 Feb 2023 12:01:00 -0800 From: Mark Millard <marklmi@yahoo.com> To: shawn.webb@hardenedbsd.org, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Dimitry Andric <dim@FreeBSD.org> Cc: David Chisnall <theraven@FreeBSD.org> Subject: Re: CFT: snmalloc as libc malloc (the nullptr_t issue) Message-ID: <22F8AD1A-C1F9-48FA-BCED-E165E2DA5260@yahoo.com> References: <22F8AD1A-C1F9-48FA-BCED-E165E2DA5260.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:5= 0: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 =3D 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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22F8AD1A-C1F9-48FA-BCED-E165E2DA5260>