Sounds complicated, but the goal of a fuzzable/sanitizable/etc libc sounds nice.<p>Lack of ABI stability sounds terrifying as an application developer. My other immediate thought was "how will this interact with systems where the OS-provided libc is the only stable way to e.g. make syscalls", and "Layering Over Another libc" addresses this. I guess the idea is you'd link an application against llvm-libc and the system libc, and ship llvm-libc with your application?
Hmm, my one question is: what platforms will this explicitly support?<p>Linux, macOS, Windows, FreeBSD, and probably OpenBSD seem shoo-in table stakes.<p>I'm more curious about<p>- iOS/iPadOS: already have a libc, but... maybe?<p>- Android: already has bionic/NDK; alternative useful?<p>- NetBSD: rump kernel/unikernel applications?<p>- VMS: has x86_64 support now; suddenly less irrelevant than before?<p>- QNX: IIUC still the best deterministic/hard real time POSIX OS...<p>- Illumos: not dead <i>yet</i>?<p>- HP-UX/AIX: still used in certain industrial applications...?<p>- Serenity: ...oh wait, just realized this isn't full POSIX, woops (would that be a prerequisite?)<p>- (what obvious thing did I forget? :P)<p>I ask this question mostly to update my understanding of "the state of kernel/OS interestingness, ~2022", since the process of deciding what targets a new major libc should consider relevant is going to be both well-informed and carefully considered given the anticipated (hoped) timescale of such a project.
I hope one day that I can statically link against my libc easily one day. Not just statically link but even LTO my libc into my binary. I understand the "security" concerns, but I feel there are cases where they don't matter.<p>Case in point; my C compiler. It already was not designed to handle untrusted input well enough and I plan to run multiple instances in parallel, so my kernel should handle COW.
In the absence any any mention of licensing, I presume this is Apache-2… I don’t know if I’ve ever seen such a core piece of infra licensed that way (am used to BSD or MIT) - others might know better than I: is this a sane way forward?
> but take advantage and use C++ language facilities for the core implementation.<p>This point sticks out. Would be nice to get some more details why it would make sense to use C++ for the implementation instead of C.
> Ability to layer this libc over the system libc if possible and desired for a platform.<p>This sounds nice for being able to use newer C/C++ library functions when targeting an older system libc by statically linking the llvm-libc implementation of the missing functions.