2 ms·

> you have to agree that it was buggy under OS X between 10.9 and 10.12 No you don't. Neither behavior has to be buggy. That's what undefined behavior means, t

by eridius 10y ago

> you have to agree that it was buggy under OS X between 10.9 and 10.12 No you don't. Neither behavior has to be buggy. That's what undefined behavior means, that any and all possible behaviors are valid because no specific behavior is defined as correct. > Linus has famously said - if you break a working userspace binary - it's a bug! That's a very hard-line stance, and it means accidents of implementation become guaranteed behavior which can be extremely restrictive down the line. Linus obviously believes that this philosophy is correct for Linux, but that doesn't mean it's correct for OS X.

blinkingled 10y ago
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!
- eridius 10y ago
  > 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.
  - blinkingled 10y ago
    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.
    - eridius 10y ago
      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.
      - blinkingled 10y ago
        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!
        10y ago

by eridius 10y ago

blinkingled 10y ago

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!

eridius 10y ago
> 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.
- blinkingled 10y ago
  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.
  - eridius 10y ago
    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.
    - blinkingled 10y ago
      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!
      - 10y ago