What is particularly interesting to me is the part where he describes why the "I should be able to expect two’s complement semantics when 32-bit signed integers overflow" line of reasoning is incorrect.<p>When I first learned about two's complement, I honestly didn't believe that that is how negative numbers were done. So I wrote a C program to test a bunch of integer operations and printf("%x") the result.<p>It was neat - here I learned something in assembly, I was curious, I observed the same behavior in my C program, and formed the connection between C, the underlying assembly, and how the architecture worked.<p>And then this article came along and said that <i>even if</i> your C program behaves a certain way, that is no guarantee that that is how the program will work in the general case. The C specification doesn't mandate that two's complement be used.<p>Which is a weird feeling; in programming, we can construct a program to test any assumption we want ("I wonder what would happen if..."). But even that is of limited value in telling us how the language works or how the program behaves in the general case, even if the language itself is intended to be cross-platform.<p>The "just write a program and see what happens" is not as reliable of a way to find a language's boundaries as I'd once thought!