For all the good things Musl does, its authors can often be downright ridiculous out of a dogmatism which is very unpleasant to deal with as a user. See also their stubborn refusal to give you an easy way to detect that the libc is Musl while compiling.

> See also their stubborn refusal to give you an easy way to detect that the libc is Musl while compiling.

I suspect that the primary use cases for that would be applying half-baked workarounds and refusing to work with an "unsupported" libc, much like HTTP User-Agent.

Or, you know, taking into account the stupid things Musl does like not having TCP DNS fallback.

I’m only half joking. Features detection in Musl is a generally pain. I don’t blame developers for sometimes taking the path of least resistance and not trying to support it.

Well, if musl is standards compliant, then wouldn't it make sense to detect when you're building on something different rather than musl? Like, if the standard didn't require TCP fallback, then in theory the application should handle that and only skip it if it detects itself being built on a libc with non-standardized extensions to obviate the effort.

Because as we all know the standard never changes potentially introducing new features, allows no variability and bugs don’t exist.

It must be nice living in your. theoretical world. Here in the real world, I like libraries to actually help me do what I want to do rather than be needlessly annoying to take a stand no one actually cares about. But that’s me. Clearly it serves Musl right given the massive amount of use it’s seeing. Hmm, wait a minute…

Okay, so nobody uses it and you can stop complaining because it'll never come up.

Well I would like to use it. It’s code is mostly sane, easier to understand than glibc and it would make sense in a lot of places where performances are not critical. That’s why I am so annoyed by the non sense its developers keep pulling out. It’s an incomprehensible situation because they get absolutely nothing out of it. They are basically annoying people for the sake of it. It’s incredible that changes like the one we are commenting on which are just sanity being restored have to come from evolution of the standard.

Standards are not laws, they are reasonably well-written documents describing behavior that is supposed to be interoperable. If, for some reason, that is not true (perhaps because the standard is ambiguous, obsolete or some other reason), ensuring that there is interoperability is more important than just keeping it to the letter of the standard.

See RFC 1925, The twelve networking truths:

(1) It has to work

Yes, it has to work. That’s exactly the point the person you’re responding to is making. There are plenty of things libc doesn’t provide. Software authors find way to provide functionality to make their software work regardless. How is DNS different? Just because you’re used to one specific implementation?

Email servers cannot use gethostbyname anyway; they never would have been affected by this issue.

I'm skeptical of that. Why do you say so?

gethostbyname() only returns an address, it can't be used to e.g. query for MX records. You also lose control over retries to different addresses if you use gethostbyname(), which some mail server software will also care about.

However as I noted in my other reply, musl also implements the res_* functions, like res_send() etc., and those can be used to address both.

It can't use gethostbyname() for looking up MX records, but plenty of mail related software have used it to look up A records.

However musl also includes res_send() etc., which can be used for MX records, and e.g. Qmail did use it back then. Here's the commit adding TCP support to those functions in Musl.

http://git.musl-libc.org/cgit/musl/commit/src/network/res_ms...

I wasn't aware musl implemented libres. I don't have a problem with libres doing TCP.

Qmail's issue was a hardcoded buffer size so this patch to musl wouldn't have helped.

The point wasn't that this would have helped Qmail - Musl didn't exist back then for that matter -, but that running into the 512 byte limit and needing TCP fallback was already a thing. Bumping a buffer size is far less effort than having to replace the resolver.