Hacker News Reader

Comment by vidarh | Hacker News Reader

Yikes. The first time I ran into an issue where email delivery for a major provider was impossible without TCP fallback was 23 years ago. To treat this as optional this long is ridiculous.

View on HN

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.

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.

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?

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 an evolution of the standard.

> 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.

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

Musl also includes res_send() etc., which can be used for MX records, and e.g. Qmail did use that 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...

AOL was the specific case we ran into that at the time (ca. 2000) returned either MX or A records (can't remember which caused the problem) that required more than 512 bytes.

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.

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.

Reply on news.ycombinator.com