ldionne wrote: > > Thanks for the explanation, @AaronBallman . I think I am generally deeply > > confused about what should be provided by the compiler and what should be > > provided by the C Standard Library on any given platform. From your reply, > > it looks like there's no clear rule and Clang basically provides anything > > that seems "easy enough" to provide. I still don't understand how that > > works in case you do end up including a header from the platform that > > (re)defines `unreachable`, for example. > > For C17 and earlier, the rule was that we provided everything required for > freestanding by the standard, and anything else the user wanted had to come > from a library the user supplied. For C23, which we're still in the process > of implementing, the situation is different and we've not documented what the > expectations are yet. I suspect we're going to end up requiring the user to > provide their own freestanding library implementation and the compiler will > provide only the bits that the compiler has to provide (things like > `limits.h`).
Thanks, this clarifies a lot of things in my head. > > Definitely agreed that we need to document this, but we need to figure out > what we want to document in the first place -- some of this is new-ish > territory because of the additional interfaces. `unreachable` is morally > similar to `offsetof` in that it's a macro interface where the implementation > can give better results by expanding to a builtin than a library is likely to > be able to give via a naive implementation, but the interfaces _can_ be > provided by a CRT. So which one _should_ win? Today, if something else > defined `offsetof` or `unreachable` before including `stddef.h`, Clang's > headers won't bother re-defining the macro. > > I think we may need to look at what existing freestanding CRTs and hosted > CRTs expect to help give us a path forward? Personally, my naive take on this is that Clang should basically define the least amount of things from the C Standard Library, and let a proper C Standard Library implement it. Having interacted with a good number of folks who work on C libraries (including embedded flavors), I think they all expect that they need to provide basically all the declarations/definitions in the C Standard, except perhaps stuff from `<stdarg.h>` and a few other oddities. Doing otherwise and trying to be "helpful" in Clang only creates confusion and forces C libraries to jump through hoops to avoid colliding with stuff already defines in Clang builtin headers. A C library is not super complicated in the first place, so I don't think we're saving a lot of people a lot of time by trying to give them a few definitions here and there. Additionally, there's many freestanding-friendly C libraries around so it's not like most people have to write their own. That's just my immediate reaction to this. It's pretty naive but at this specific point I believe we should basically not provide any Clang builtin headers except the ones that clearly provide compiler-related stuff (e.g. `<stdarg.h>` or `tmmintrin.h` & friends). I'm eager to hear other people's takes on this. SLA note: I'll be OOO for a few days so I'll only see replies early next week. 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
