I agree this with as some one working at a company that avoids most open source like the plague. But in this particular case, the code quality in musl is pretty good. I haven't had an issue with it so far, and after trying to upstream some things in glibc I have to say I can't see why they wouldn't use musl.
Well, there are still huge holes in musl. towlower e.g uses a linear search. my binary search made it 2x faster, but we still have to wait for that to appear. Implemented Unicode standards are years old.
You don't know which standard is implemented.
Still many problems with dynamic linking.
And: musl is POSIX. POSIX blocking IO should not be used in a modern OS or language. You can never guarantee concurrency safety with POSIX. This is the Fuchsia problem. They went for unsafety and POSIX compat. L4 ditto. Microsoft's Singularity not.
A modern libc would need to get rid of blocking IO and implement strings as utf8 only. There's no need for anything else. The C standard made too many mistakes.
I don't see how you're planning on writing a libc that chooses to interpret the C standard as full of "mistakes" without writing an entirely different language.
I'm already maintaining the libc security extensions, which are in the standard but all libc's refuse to implement.
I also added the missing string API's for the wrong wide API, but thinking about adding the proper u8 api instead. Nobody really should use the wide (UTF-32/UTF-16) api.
But the C standard committee is somewhere completely else. There are not even aware of the problems, even if I'm getting interviewed from time to time, so that they will change their attitudes towards insecurity and functionality. searching for strings should be a pretty common usage pattern, but it's still not implemented. coreutils or grep or sed would like to use it, I'm sure. But not 10x slower as the current multibyte patches. Which I'm also maintaining btw. for coreutils.
Non-blocking IO into the standard? I only know about libuv which was fine before the drama. Despised it since then, but I'm still using it. The standard mostly needs to provide a namespace to block blocking IO if someone needs a concurrency-safe subset. Then the unhealthy need for POSIX compat can be circumvented somewhat. And gets() can be finally.
What problems with dynamic linking? Considering docker and most container Linux systems use musl im sure they wouldnt mind knowing. Also musl has no problem having utf8 strings, in fact its one of the highlighted features.
pthread and dynamic linking: Look at their bug reports and mailing list discussions.
musl has no problem with utf8, because musl doesn't implement an utf8 string api. musl is strict C11. This is one of the problems. Most libc's do have this problem.
There is casefolding, which is small but too slow (as explained). And 6 years behind. (Unicode 6.0 vs 12.1)
There's no normalization at all, so you cannot search for strings, just for memory buffers. Which leads to insecure identifier handling, such as all public names, paths, ... There is a lot of identifier API in C11 and various syscalls/kernels, which are all insecure. Not musl's or any libc fault, but they should lead the pack, not follow wrong standards.
Having checked unicode collate handling, guess there's none neither. It's planned for later this year I read.
Unicode (the "wide" api) is UTF-32 which is too big and too slow.
