Live data from Hacker News

A Guide to Undefined Behavior in C and C++ (2010)

blog.regehr.org

11–13 of 13 posts

Re: A Guide to Undefined Behavior in C and C++ (2010)

#11
post #10

Isn't complaining that (INT_MAX + 1) is undefined the same as complaining that (8/0) is undefined? What meaningful functionality could be gained by defining overflow behavior? If you really want to know what INT_MAX + 1 is, try: printf("INT_MAX+1= %lld\n", (long long)INT_MAX + 1LL);

I'm only speaking for my personal preferences here.

My two problems with undefined behavior is that 1) it is not always obvious that your program is guilty of undefined behavior and 2) when a C program contains undefined behavior the compiler can generate surprising machine code.

I don't have any problem with 8/0 being undefined mathematically, but I do have a problem with a C compiler generating code that will delete my hard drive if it ever occurs (an unlikely but theoretically possible for a conforming C compiler).

INT_MAX + 1 is problematic because most people expect wrap around (and in fact they may be using a compiler that does this). It's more problematic because UINT_MAX + 1 does get wrap around. And finally there's a bunch of difficult to remember auto integer conversion rules. Taken together it's not surprising that many people will find it difficult to determine if their integer usage is correct.

One solution is of course to use a safer language than C (where I unfortunately have to end up). But I personally object to the idea that you have to have undefined behavior in order to get the performance of C (waiting to see how the development of languages like Rust goes to determine if I'm right).

Re: A Guide to Undefined Behavior in C and C++ (2010)

#12
post #10

Isn't complaining that (INT_MAX + 1) is undefined the same as complaining that (8/0) is undefined? What meaningful functionality could be gained by defining overflow behavior? If you really want to know what INT_MAX + 1 is, try: printf("INT_MAX+1= %lld\n", (long long)INT_MAX + 1LL);

I think a good middle-ground would be to have more narrowly scoped behavior. Not quite implementation-defined (as I believe that requires the implementation to be consistent in its treatment?) but for instance "Integer overflow will result in the integer taking an unspecified (and potentially changeable) valid value for that integer". I'm not sure whether that particular example sufficiently covers the requirements of the optimiser, but defining it as "May cause any of the following results, but not nasal demons" would perhaps be an improvement?

DISCLAIMER: I haven't done any C programming in years, and I wasn't particularly good at it, even then.

Re: A Guide to Undefined Behavior in C and C++ (2010)

#13
post #11
post #10

Isn't complaining that (INT_MAX + 1) is undefined the same as complaining that (8/0) is undefined? What meaningful functionality could be gained by defining overflow behavior? If you really want to know what INT_MAX + 1 is, try: printf("INT_MAX+1= %lld\n", (long long)INT_MAX + 1LL);

I'm only speaking for my personal preferences here. My two problems with undefined behavior is that 1) it is not always obvious that your program is guilty of undefined behavior and 2) when a C program contains undefined behavior the compiler can generate surprising machine code. I don't have any problem with 8/0 being undefined mathematically, but I do have a problem with a C compiler generating code that will delet…

There exists an enormous body body of reliable and fast code written in "C" (e.g. the Linux kernel). I've been coding in C for 27 years, C++ for 20. I think the idea that a language can permit only useful work to occur is naive. In order to code well, the programmer must understand how the computer works, and have a great deal of focus. If you have those, "helpful" languages only seem to get in the way.
Post reply on HN