On: You Can't Always Hash Pointers in C

[lmm]

Can you give an example? I struggle to think of anywhere the standard uses a wording that would fit here.

[jjnoakes → lmm]

Why would it have to be wording already in the standard? Does each phrasing in the standard have to appear more than once?

[lmm → jjnoakes]

Adding a new phrase with a new meaning would add a substantial amount of complexity to what's already a very complex standard.

[jjnoakes → lmm]

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 → jjnoakes]

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 → lmm]

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 → jjnoakes]

> 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.