bcraig added a comment. Let's talk about these use cases.
> On the one hand, I think many users will want a libc that targets their > particular freestanding environment so that they get the best performance > characteristics (and other considerations) for their target. I think this fits kernel driver environments, GPUs, and other environments where the vendor is heavily involved in compiler development. The vendor is likely to provide extensions to their freestanding implementation as well (like math.h functions for GPUs). > On the other hand, I think a not-insignificant number of users are interested > in freestanding environments for one-off/fun/experimental projects where ease > of access is more important than performance characteristics -- think: users > who are playing around with an arduino, etc. This is also an important use case. I don't think it rules out a "stock" freestanding implementation though. A toolchain could reasonably ship one freestanding static library for each ISA-subset / target-triple they want to support, and it could work regardless of the target operating system. `memcpy` has the same assembly whether it's on OpenRTOS or threadx or MyHomeGrownOS, so long as all are on the same processor with the same calling conventions. A toolchain could also try the header-only approach and lean on the optimizer to turn `strcpy` into reasonable assembly. I will definitely agree on the big point with this use case though. I don't want to force every OS vendor to also need to be a compiler / libc vendor, so long as they are willing to settle for the freestanding subset of the language. I also don't want to force them to rewrite `strcpy` and friends. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144889/new/ https://reviews.llvm.org/D144889 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
