Date: Sun, 12 Feb 2023 14:32:56 -0800 From: Mark Millard <marklmi@yahoo.com> To: Shawn Webb <shawn.webb@hardenedbsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, David Chisnall <theraven@FreeBSD.org> Subject: Re: CFT: snmalloc as libc malloc Message-ID: <0F63E50F-C0DF-48C4-81A0-6EEF46C9C397@yahoo.com> In-Reply-To: <AE89E235-DD25-4D4B-BAC1-BA9956F904B0@yahoo.com> References: <ED93FF21-07BC-4FC0-A114-27424E60C024@yahoo.com> <20230212210904.nzxfwtzsjf2tu6ky@mutt-hbsd> <AE89E235-DD25-4D4B-BAC1-BA9956F904B0@yahoo.com>
index | next in thread | previous in thread | raw e-mail
[Just making my notes more complete, mentioning the C++ use of #include_next <stddef.h> and the ordering implication for include/c++/v1 vs. where the normal C headers are in the search list (for C headers that C++ tries to use).] On Feb 12, 2023, at 13:48, Mark Millard <marklmi@yahoo.com> wrote: > On Feb 12, 2023, at 13:09, Shawn Webb <shawn.webb@hardenedbsd.org> wrote: > >> . . . >> That does not include the extra text that would be generated >> by having added the -v requested to that shown command line. >> That tet would likely have been before the text that you did >> include. >> >> Did you add the -v option? Was there extra text? > > Good catch. I missed reading that. Here's the new output: > http://ix.io/4nSy > > Hmm. Scanning that list . . . > > #include "..." search starts here: > #include <...> search starts here: > /data/src/hardenedbsd/lib/libc/include > /data/src/hardenedbsd/include > > The above likely includes a non-C++: stddef.h > That likely overrides any: . . ./include/c++/v1/stddef.h > that is required for things to work for the > nullptr_t issue. (See prior E-mail from when > I noticed that I'd missed the include/c++/v1/stddef.h > involved.) > > /data/src/hardenedbsd/lib/libc/amd64 > /data/src/hardenedbsd/contrib/gdtoa > /data/src/hardenedbsd/contrib/libc-vis > /usr/obj/data/src/hardenedbsd/amd64.amd64/lib/libc > /data/src/hardenedbsd/lib/libc/resolv > /data/src/hardenedbsd/lib/libmd > /data/src/hardenedbsd/lib/libc/locale > /data/src/hardenedbsd/lib/libc/rpc > /data/src/hardenedbsd/lib/libutil > /data/src/hardenedbsd/lib/msun/amd64 > /data/src/hardenedbsd/lib/msun/x86 > /data/src/hardenedbsd/contrib/snmalloc/src/snmalloc > /usr/obj/data/src/hardenedbsd/amd64.amd64/tmp/usr/include/c++/v1 > > The above looks to be the first/only chance to pick > up a C++ based file header (that may in turn look > for a C based one as well). > > /usr/lib/clang/15.0.7/include > /usr/obj/data/src/hardenedbsd/amd64.amd64/tmp/usr/include > /data/src/hardenedbsd/lib/msun/src > End of search list. > > The ordering does not look anything like correct > to me relative to C++ headers, some of which in > turn may include the C variants from the environment. I'll note that include/c++/v1/stddef.h uses: #include_next <stddef.h> That in turn causes a stddef.h to be found that is from later in the search list (not earlier or the same file again). As for the include ordering, this leads to . . ./include/c++/v1 needing to be before the directory for the matching normal C header(s) that C++ is(are) trying to include. There are implications for recursive include handling during #include_next processing (just the tail of the search list is used as I understand). > It is not so clear to me what the relationship is > to the source_location file issue. === Mark Millard marklmi at yahoo.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0F63E50F-C0DF-48C4-81A0-6EEF46C9C397>