Re: CFT: snmalloc as libc malloc

[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.com