11 ms·

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 popu

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!
  - eridius 10y ago
    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.
    - blinkingled 10y ago
      At this point I am convinced you cannot be serious - your comment history is proof enough for me. (Next time I'll spot you sooner ;)
      - eridius 10y ago
        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.
      - dang 10y ago
        This comment violates the HN guidelines. Please don't post uncivilly again.

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!
- eridius 10y ago
  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.
  - blinkingled 10y ago
    At this point I am convinced you cannot be serious - your comment history is proof enough for me. (Next time I'll spot you sooner ;)
    - eridius 10y ago
      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.
    - dang 10y ago
      This comment violates the HN guidelines. Please don't post uncivilly again.