AaronBallman wrote: > > > Why do the Clang builtin headers even try to define this? Shouldn't this > > > be provided by the platform's C library instead? I am really confused > > > about what's the intended layering here and it seems to me like Clang is > > > overstepping its responsibilities by basically implementing parts of the > > > C library. > > > > > > I did that in > > [a9797d7](https://github.com/llvm/llvm-project/commit/a9797d7d2d7878464868312e0c147b4e747a31c6) > > It's a freestanding feature in C23, so we need to expose it from `stddef.h` > > at least when not in hosted builds. I don't understand why this is making > > into C++ builds at all: > > Thanks for the explanation. I think I don't understand the relationship > between that feature being freestanding and the fact that it's implemented in > the Clang builtin headers. I might be misunderstanding (or just ignorant of) > the Clang approach for freestanding in C. Doesn't Clang still rely on there > being a C library even in Freestanding mode?
In C, freestanding used to be "here's a pile of macros", so the compiler was able to easily supply a freestanding set of headers. That's changed with C23 (for example, we now include `string.h` and `stdbit.h` in freestanding, both of which provide a lot of function interfaces). I don't think we've documented an official policy one way or the other about what level of CRT support needs to come from outside of the compiler, but given that `unreachable` is a macro that expands to a builtin, it is a very reasonable thing for us to expose from our freestanding headers (there's no underlying library support needed, at least in theory). It's somewhat akin to supplying `offsetof` which is also a function-like macro that expands to a builtin. https://github.com/llvm/llvm-project/pull/86748 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
