Conversation

I think they primarily care about Fuchsia support, where they use a fork of musl ported over to Fuchsia and with some added features. I think the chance is pretty low of musl supporting Fuschsia upstream, but they could probably land a fair bit of what they need upstream.
2
I doubt it has anything to do with Android though. I'm not sure why they would want it if not for Fuchsia support. There are a lot of things they use that aren't in musl right now but other than Fuchsia support I think most of it would be welcome there, even if a bit reluctantly.
1
I have a good idea of what's missing from musl for their needs though, and it doesn't make any sense for them to make a whole new libc if it's only for Linux. Having it in LLVM also implies needing to deal with more portability, including deciding how to approach Windows support.
1
I could see people wanting a libc portable across *BSD, Linux, maybe even Windows, etc. I can't understand why Google would want to deal with maintaining that, so that's why I assumed it was compelled by their current fork of musl in Fuchsia. I'm not understanding the reasoning.
1
My vague summary -- will continue in that thread...
Quote Tweet
Replying to @jckarter @DanielMicay and 3 others
I'd expect them to discuss that? Maybe not, dunno. Twitter isn't great but some things I recall from my (limited) involvement: - Testing methodology concerns - Fuzzing / sanitizer integration - Simplifications from static-only model - Code density / complexity / docs - Community
1