5 ms·

Implementation-defined includes trapping on overflow.

lmm 10y ago
"Evaluates to an implementation-defined value" would not include that. I'm not sure if any of the usual definitions in the standard includes trapping and doesn't include arbitrary behaviour.
- jjnoakes 10y ago
  Sure, but the standard need not say "Evaluates to an implementation-defined value". There are other wordings which use "implementation-defined" and would support trapping on overflow.
  - lmm 10y ago
    Can you give an example? I struggle to think of anywhere the standard uses a wording that would fit here.
    - jjnoakes 10y ago
      Why would it have to be wording already in the standard? Does each phrasing in the standard have to appear more than once?
      - lmm 10y ago
        Adding a new phrase with a new meaning would add a substantial amount of complexity to what's already a very complex standard.
        jjnoakes 10y ago
        I disagree. There's nothing difficult to understand about new phrases with new meanings in general. Do you have a specific phrase which you can show to be sufficiently difficult to understand by a group of people, and which you don't think could be rewritten to retain the same meaning but be easier to understand? If you do, let me know, and I will try to simplify it for you and help you understand it. If you don't, then there isn't much to say. Your current argument ("phrases could be written in a difficult to understand way") is too general to be useful.
        lmm 10y ago
        I suppose it's less the phrase itself than the concept. What would be a way to say "integer overflow behaviour may reflect the underlying machine, but must be sensible", rigorously enough for the C standard? We've established that "undefined behaviour" is too broad, and "implementation-defined value" is too narrow.
        jjnoakes 10y ago
        Why "must be sensible"? Why not just say "signed integer overflow is implementation-defined" and in a footnote say "for example, it may wrap, trap, saturate, or do anything else documented by your implementation"? I'm not seeing the big deal here.
        lmm 10y ago
        > Why "must be sensible"? Why not just say "signed integer overflow is implementation-defined" and in a footnote say "for example, it may wrap, trap, saturate, or do anything else documented by your implementation"? I don't think that actually defines anything - I don't think GCC would interpret that as anything other than undefined behaviour.
- caf 10y ago
  Well, there's kind of one place: when a value is converted to a signed type and it's out of range for that type, the standard says "either the result is implementation-defined or an implementation-defined signal is raised." However, integer overflow within an expression is trickier than this to define, because you want to preserve the compiler's ability to reorder sub-expressions that are mathematically equivalent when there's no overflow, without forcing the compiler to prove that there won't be overflow. The same is true of CSE and hoisting expressions out of loops. For example, if you have a machine that traps on overflow and thus under this hypothetical standard your implementation defined signed overflow to trap, you can't simplify (a + 2 - 1) to (a + 1) because the second might trap when the second does not, and your implementation has said that the trap will happen. It also means that you can't hoist an expression out of a loop if that expression might overflow, because the trap has to happen at the point where it would happen on the C virtual machine, not later after other side-effects have become visible. This is why trapping implementations imply "undefined behaviour" - it's because defining to trap severely restricts the compiler's freedom under the as-if rule to reorder and simplify expressions.
deleted 10y ago
[deleted]

lmm 10y ago

"Evaluates to an implementation-defined value" would not include that. I'm not sure if any of the usual definitions in the standard includes trapping and doesn't include arbitrary behaviour.

jjnoakes 10y ago
Sure, but the standard need not say "Evaluates to an implementation-defined value". There are other wordings which use "implementation-defined" and would support trapping on overflow.
- lmm 10y ago
  Can you give an example? I struggle to think of anywhere the standard uses a wording that would fit here.
  - jjnoakes 10y ago
    Why would it have to be wording already in the standard? Does each phrasing in the standard have to appear more than once?
    - lmm 10y ago
      Adding a new phrase with a new meaning would add a substantial amount of complexity to what's already a very complex standard.
      - jjnoakes 10y ago
        I disagree. There's nothing difficult to understand about new phrases with new meanings in general. Do you have a specific phrase which you can show to be sufficiently difficult to understand by a group of people, and which you don't think could be rewritten to retain the same meaning but be easier to understand? If you do, let me know, and I will try to simplify it for you and help you understand it. If you don't, then there isn't much to say. Your current argument ("phrases could be written in a difficult to understand way") is too general to be useful.
        lmm 10y ago
        I suppose it's less the phrase itself than the concept. What would be a way to say "integer overflow behaviour may reflect the underlying machine, but must be sensible", rigorously enough for the C standard? We've established that "undefined behaviour" is too broad, and "implementation-defined value" is too narrow.
        jjnoakes 10y ago
        Why "must be sensible"? Why not just say "signed integer overflow is implementation-defined" and in a footnote say "for example, it may wrap, trap, saturate, or do anything else documented by your implementation"? I'm not seeing the big deal here.
        lmm 10y ago
        > Why "must be sensible"? Why not just say "signed integer overflow is implementation-defined" and in a footnote say "for example, it may wrap, trap, saturate, or do anything else documented by your implementation"? I don't think that actually defines anything - I don't think GCC would interpret that as anything other than undefined behaviour.
caf 10y ago
Well, there's kind of one place: when a value is converted to a signed type and it's out of range for that type, the standard says "either the result is implementation-defined or an implementation-defined signal is raised." However, integer overflow within an expression is trickier than this to define, because you want to preserve the compiler's ability to reorder sub-expressions that are mathematically equivalent when there's no overflow, without forcing the compiler to prove that there won't be overflow. The same is true of CSE and hoisting expressions out of loops. For example, if you have a machine that traps on overflow and thus under this hypothetical standard your implementation defined signed overflow to trap, you can't simplify (a + 2 - 1) to (a + 1) because the second might trap when the second does not, and your implementation has said that the trap will happen. It also means that you can't hoist an expression out of a loop if that expression might overflow, because the trap has to happen at the point where it would happen on the C virtual machine, not later after other side-effects have become visible. This is why trapping implementations imply "undefined behaviour" - it's because defining to trap severely restricts the compiler's freedom under the as-if rule to reorder and simplify expressions.

deleted 10y ago

[deleted]