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

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.