I was under the impression that musl does care about standards compliance, hitting problems mostly when people expect non-standardized behavior.

Musl is somewhat the embodiment of malicious compliance to the standard.

musl has a better track record of standards compliance than glibc. Common method for porting to musl is putting non-standard compliant code into an ifdef glibc.

Counterexample: musl's crypt() does silly things, like treat all unrecognized inputs as DES, even if the salt characters are invalid.

at least it actually supports blowfish

This is, of course, the same musl that refused to implement TCP DNS requests until very recently. And they only did so because the DNS standards people got fed up with people not implementing it, and made it a requirement.

And glibc is the one not implementing strlcpy and strlcat until June 2023.

strscpy is the better API anyway

It was made a requirement by RFC 7766 in 2016 https://www.rfc-editor.org/rfc/rfc7766#page-6

That doesn't necessarily contradict "the DNS standards people got fed up with people not implementing it, and made it a requirement."?

It took musl about 6 years to implement the requirement.

[delayed]

pretty much the only place where it's meaningfully slower is the allocator (which has a massive impact) so in chimera we have a special musl build that uses llvm's scudo instead (same as e.g. android) and is faster as well as more secure than glibc's allocator

the rest is mostly fewer specialized implementations of stuff for different cpus, but that rarely makes a difference in practice (i.e. outside of microbenchmarks)

the overall standards compliance is pretty good in musl