I think this is going beyond reason - not correct for OS X?! What does that mean? It's not just Linux either - MS does the same thing. You don't cause developers and users pain by randomly changing stuff - correct or incorrect to you doesn't factor. If something was working it is a reasonable expectation for any mainstream OS that it will continue to work. If you don't agree with that then your choice - the world hasn't worked that way in a while.

It would be one thing if they always consistently returned immediately in poll if you passed NULL but alternating between returning immediately and returning after timeout with no guarantee which OS version will change it again in future - that's madness. Hey but ok - for you I will say it - Apple can do no wrong!

> You don't cause developers and users pain by randomly changing stuff

That's different than the hard-line stance that Linus takes. Either you're deliberately mischaracterizing what's going on, or you don't actually understand what you were referencing.

In any case, just because some API behaved in a particular way in a degenerate possibly-undefined case doesn't mean the OS needs to preserve that behavior in the future. It was probably an artifact of implementation, so if the implementation changes, the undefined behavior may change too. And that's perfectly alright, if it's undefined behavior. Sure, if you are aware of the particular behavior and aware that apps are relying on it, and it's not an undue burden, then it's a good idea to preserve the existing behavior. But that's a lot of "ifs" there.

So you are saying you will feel better if you made the assumption that it is a burden for Apple to stick to one behaviour _and_ you will ignore that a very popular library curl was depending on it and so far had to twice adjust their code. But yeah we will assume undue burden for Apple to keep it working one way.

And No, I am not misunderstanding anything I am sure - as are the libcurl authors! You so far seem to be the only person arguing otherwise with no proof that there is undue burden for Apple while ignoring causing impact s twice for not an obscure library! Ok, I'm done here.

If it's undefined behavior, libcurl shouldn't be depending on it. And the fact that they were bitten by this behavior in the past makes me wonder why they decided to depend on the behavior since then. And I'm definitely not the only person arguing otherwise because what got me thinking that this might be undefined behavior was someone else's comment arguing that. Besides, popular opinion is not what defines a spec, so even if I was the only person arguing this way that wouldn't mean anything.

That is NOT undefined behavior. That is at the most not-clearly-defined behavior that is bounded, with TWO possible outcomes - Apple switches between those (not at runtime - but across OS releases!!) and that's not correct in any sense of the word! Dereferencing NULL/Wild/free()ed pointer (again not applicable to this case - we are not dereferencing the NULL FD set - NULL here specifies empty) is undefined behavior - not specified if that will fail silently or cause you to call a function or trap or a hundred other things - not bounded or in other words without specific choices. Vastly different from either return after timeout or immediately. Do one thing consistently, preferably same as what other UNIXes are doing, or if you do otherwise stick to it. This isn't undefined behavior where code does something and result can be unknown - this is deliberate behavior!

There are more than 2 possible choices if you read the spec as leaving the empty set case undefined. There's 2 choices that are likely to result, but that doesn't mean the implementation can't do something else instead.

> Apple switches between those (not at runtime - but across OS releases!!) and that's not correct in any sense of the word!

Assuming it's undefined, then sure it is. Linus treats accidental implementation-defined behavior as guaranteed in Linux. But Apple only guarantees documented behavior. If something is undocumented, Apple is free to change it. In practice, they try to keep backwards compatibility (even going to such lengths as preserving old bugs for certain apps based on bundle ID), but that doesn't mean they guarantee backwards compatibility for undocumented behavior, or that they're wrong when they change something that affects undocumented behavior.

> This isn't undefined behavior where code does something and result can be unknown - this is deliberate behavior!

Given that the behavior changed, I'm willing to bet it's not deliberate behavior but is an artifact of implementation.

This comment violates the HN guidelines. Please don't post uncivilly again.

Now you're just being deliberately offensive. I do not appreciate you implying that I'm a troll. I've been nothing but honest throughout this whole discussion and have explained my reasoning many times. The fact that you interpret your disagreement with me as proof that I'm a troll is incredibly arrogant.