A Guide to Undefined Behavior in C and C++, Part 1

blog.regehr.org

37 points·larelli··2 comments

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.

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.

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.

And then this article came along and said that even if 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.

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.

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!

For me, the second stage in the evolution as a C or a C++ programmer after a discovery like this was to start relying heavily on language standards. After all, it's the ultimate reference about how the language should work on all platforms and compilers.

But then I learn that not all compilers behave exactly the same way, or implement only a subset of a standard for a variety of reasons (every compiler would implement different subsets), and I return full circle back to experimentation with individual implementations.

Reply on news.ycombinator.com