On 06/18/13 11:07, Rich Felker wrote: > Of my two > proposed fixes, the first would fix the issue on any future system > that's not broken (not just existing ones), but would obviously not > support future broken systems.
But we're not talking about "future" systems here; we're merely talking about unported-to systems, not all of which are future systems. Nor are we talking about "broken" systems; we're merely talking about systems that do not conform to POSIX -- they may conform to C11, say, without conforming to POSIX. So this first fix sounds problematic. > The second proposed fix should support > any future system, but would be a bit more costly, assuming it's even > possible. That would be better, yes. But it'd be more work to implement than method (3) would be. > To revisit why I don't like your proposed fix, for every bug we could > get fixed by making an easy way for applications to test "is this > musl?", we would have something like 10 new bugs created by people > doing that. This is not just speculation; it's based on questions we > get on the list and on IRC. Your idea of using such a test in the form > of "if (is_musl) assume_non_broken();" is the first proposed use of > this form I've seen. Every other request for an easy "if (is_musl)" > test have been from people who wanted to do something that would cause > bad breakage with future versions of musl. I'm afraid I don't follow this reasoning. Are you saying that, method (3) is OK here but its use here might encourage people to use it in other places where it's not OK? If so, let's add a comment warning people to use method (3) carefully.