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

Edit: I was responding to someone saying `(INT_MAX+1)` was implementation defined so couldn't go skynet; and I was asking honestly because the C standard is twisty as heck and maybe they knew something I didn't.

___

Isn't it undefined because of signed integer overflow? Or at least implementation defined whether it's undefined or not?

The C standard (n1570) even uses integer overflow as an example of undefined behavior in section 3.4.3

> An example of undefined behavior is the behavior on integer overflow

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

#5

Post by [deleted] » Tue, Jul 14, 2015, 6:14 PM UTC

missblit wrote: post #4

[deleted] wrote: post #3

[deleted]

Edit: I was responding to someone saying `(INT_MAX+1)` was implementation defined so couldn't go skynet; and I was asking honestly because the C standard is twisty as heck and maybe they knew something I didn't. ___ Isn't it undefined because of signed integer overflow? Or at least implementation defined whether it's undefined or not? The C standard (n1570) even uses integer overflow as an example of undefined behavi…

[deleted]

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

#6

Post by tedunangst » Tue, Jul 14, 2015, 6:38 PM UTC

> undefined behavior in C/C++ is that it simplifies the compiler’s job, making it possible to generate very efficient code in certain situations.

I've been growing more skeptical of this claim over time. First, more evidence would be nice instead of "some loops". What is a program (not a benchmark) that has an observable performance difference when compiled with and without -fwrap?

Second, it seems counter productive. The word is now out that if you use signed ints, the compiler is going to fuck you over. So now everybody is (or should be) using unsigned ints, and whatever optimization the compiler was performing, now it can't. A lot of grief for no progress.

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

#7

Post by pcwalton » Tue, Jul 14, 2015, 6:46 PM UTC

tedunangst wrote: post #6

> undefined behavior in C/C++ is that it simplifies the compiler’s job, making it possible to generate very efficient code in certain situations. I've been growing more skeptical of this claim over time. First, more evidence would be nice instead of "some loops". What is a program (not a benchmark) that has an observable performance difference when compiled with and without -fwrap? Second, it seems counter productive…

> I've been growing more skeptical of this claim over time. First, more evidence would be nice instead of "some loops". What is a program (not a benchmark) that has an observable performance difference when compiled with and without -fwrap?

Google brings up this old message. It seems to affect the SPEC2000 suite fairly badly. SPEC2000 mostly measures real applications, such as gzip, and is not a series of microbenchmarks.

http://www.archivum.info/autoconf-patches@gnu.org/2007-01/00...

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

#8

Post by tedunangst » Tue, Jul 14, 2015, 7:13 PM UTC

pcwalton wrote: post #7

tedunangst wrote: post #6

> undefined behavior in C/C++ is that it simplifies the compiler’s job, making it possible to generate very efficient code in certain situations. I've been growing more skeptical of this claim over time. First, more evidence would be nice instead of "some loops". What is a program (not a benchmark) that has an observable performance difference when compiled with and without -fwrap? Second, it seems counter productive…

> I've been growing more skeptical of this claim over time. First, more evidence would be nice instead of "some loops". What is a program (not a benchmark) that has an observable performance difference when compiled with and without -fwrap? Google brings up this old message. It seems to affect the SPEC2000 suite fairly badly. SPEC2000 mostly measures real applications, such as gzip, and is not a series of microbenchm…

Interesting, though I still wonder to what extent this is a result of optimizations chasing SPEC. Alternatively, could similar optimizations be made to work with defined behavior? (How will rust fair with "less undefined" behavior?) As I mentioned, it's kind of crazy that I might substantially impair the performance of gzip by changing a few ints to unsigned.

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

#9

Post by Verdex » Tue, Jul 14, 2015, 7:39 PM UTC

tedunangst wrote: post #6

> undefined behavior in C/C++ is that it simplifies the compiler’s job, making it possible to generate very efficient code in certain situations. I've been growing more skeptical of this claim over time. First, more evidence would be nice instead of "some loops". What is a program (not a benchmark) that has an observable performance difference when compiled with and without -fwrap? Second, it seems counter productive…

I really like your second point. That's kind of a difficult failure case to try and mitigate.

I've been vaguely concerned with how to ensure my C code avoids undefined behavior, but it didn't occur to me that I also need to watch out in being overly conservative because then I'll be causing the optimizers trouble.

I'm not trying to disparage anyone who is actually able to be productive in a C environment, but I'm really hoping something like Rust is able take over that development space.

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

#10

Post by jrbrtsn » Tue, Jul 14, 2015, 8:58 PM UTC

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);