Integer overflow in C: standards and compilers

Question

Edited to include proper standard reference thanks to Carl Norum.

The C standard states

If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined.

Are there compiler switches that guarantee certain behaviors on integer overflow? I'd like to avoid nasal demons. In particular, I'd like to force the compiler to wrap on overflow.

For the sake of uniqueness, let's take the standard to be C99 and the compiler to be gcc. But I would be interested in answers for other compilers (icc, cl) and other standards (C1x, C89). In fact, just to annoy the C/C++ crowd, I'd even appreciate answers for C++0x, C++03, and C++98.

Note: International standard ISO/IEC 10967-1 may be relevant here, but as far as I could tell it was mentioned only in the informative annex.

score 26 · Accepted Answer · edited Jun 20 '20 at 09:12

26

Take a look at -ftrapv and -fwrapv:

-ftrapv

This option generates traps for signed overflow on addition, subtraction, multiplication operations.

-fwrapv

This option instructs the compiler to assume that signed arithmetic overflow of addition, subtraction and multiplication wraps around using twos-complement representation. This flag enables some optimizations and disables other. This option is enabled by default for the Java front-end, as required by the Java language specification.

edited Jun 20 '20 at 09:12

Community

1
1

answered Sep 09 '10 at 17:48

Matt Joiner

112,946
110
377
526

1

Excellent, just what I wanted to see. Is there anything comparable for unsigned types? – Charles Sep 09 '10 at 17:53
3

@Charles you don't need them for unsigned types - overflow behaviour is already well-defined for them (see my answer). – Carl Norum Sep 09 '10 at 18:00
@Carl Norum: I see that it's defined in C++, and that it's defined in C for shifts (6.5.7 para 5). I can't see where it's defined in the C standard for addition and multiplication. – Charles Sep 09 '10 at 18:03
1

@Charles - 6.2.5 paragraph 9: "A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type." – Carl Norum Sep 09 '10 at 18:10
13

Note that `-fwrapv` does **not** guarantee that overflow will wrap. All it does is tell the optimiser that it can *assume* that that's the case. Whether it really is true depends on your machine architecture. – caf Sep 10 '10 at 02:20
1

@caf: Do you know if there are any distinctions on how -fwrapv and -fno-strict-overflow affect transforms which may affect wrapping behavior, e.g. turning "int1+int2+long1" into "(int1+long1)+long2"? I would think it would be useful to have an option to enable precise wrapping and an option to explicitly accept any result which is congruent to the correct result (mod the integer size), since each behavior may be needed in certain situations. – supercat Apr 04 '16 at 15:50

Carl Norum · Answer 2 · 2010-09-09T17:51:23.900

For your C99 answer, I think 6.5 Expressions, paragraph 5 is what you're looking for:

If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined.

That means if you get an overflow, you're out of luck - no behaviour of any kind guaranteed. Unsigned types are a special case, and never overflow (6.2.5 Types, paragraph 9):

A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type.

C++ has the same statements, worded a bit differently:

5 Expressions, paragraph 4:

If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined. [Note: most existing implementations of C++ ignore integer overflows. Treatment of division by zero, forming a remainder using a zero divisor, and all floating point exceptions vary among machines, and is usually adjustable by a library function. —endnote]
3.9.1 Fundamental types, paragraph 4:

Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2^n where n is the number of bits in the value representation of that particular size of integer.

Yes, that's what I was looking for. (Though the reference confused me at first -- that's 6.5 paragraph 5, not section 6.5.5.) Do you know of any way to avoid this? Wrapping on overflow is common, and there are many times when I want this to happen. Do any popular compilers have a switch that makes them promise to wrap? — Charles, Sep 09 '10 at 17:49
@Charles, undefined behaviour is undefined. You may get lucky with your particular compiler - check its documentation for a statement that will give you peace of mind. In `gcc`, for example, you can check out the `-fstrict-overflow` and `-fwrapv` flags. — Carl Norum, Sep 09 '10 at 17:52

score 7 · Answer 3 · answered Sep 09 '10 at 17:46

In C99 the general behavior is desribed in 6.5/5

If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined.

The behavior of unsigned types is described in 6.2.5/9, which basically states that operations on unsigned types never lead to exceptional condition

A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type.

GCC compiler has a special option -ftrapv, which is intended to catch run-time overflow of signed integer operations.

score 5 · Answer 4 · answered Sep 01 '13 at 21:14

5

For completeness, I'd like to add that Clang now has "checked arithmetic builtins" as a language extension. Here is an example using checked unsigned multiplication:

unsigned x, y, result;
...
if (__builtin_umul_overflow(x, y, &result)) {
    /* overflow occured */
    ...
}
...

http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins

answered Sep 01 '13 at 21:14

Viktor Söderqvist

351
2
5

1

GCC has integer overflow builtins too nowdays. See https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html. – Viktor Söderqvist Oct 05 '21 at 16:57

score 2 · Answer 5 · answered Sep 09 '10 at 18:00

6.2.5 paragraph 9 is what you're looking for:

The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the representation of the same value in each type is the same.31) A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type.

Guenther Brunthaler · Answer 6 · 2019-04-27T19:09:40.623

The previous postings all commented on the C99 standard, but in fact this guarantee was already available earlier.

The 5th paragraph of Section 6.1.2.5 Types

of the C89 standard states

A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned integer type.

Note that this allows C programmers to replace all unsigned divisions by some constant to be replaced by a multiplication with the inverse element of the ring formed by C's modulo 2^N interval arithmetic.

And this can be done without any "correction" as it would be necessary by approximating the division with a fixed-point multiplication with the reciprocal value.

Instead, the Extended Euclidian Algorithm can be used to find the inverse Element and use it as the multiplier. (Of course, for the sake of staying portable, bitwise AND operations should also be applied in order to ensure the results have the same bit widths.)

It may be worthwhile to comment that most C compilers already implement this as an optimization. However, such optimizations are not guaranteed, and therefore it might still be interesting for programmers to perform such optimizations manually in situations where speed matters, but the capabilities of the C optimizer are either unknown or particularly weak.

And as a final remark, the reason for why trying to do so at all: The machine-level instructions for multiplication are typically much faster than those for division, especially on high-performance CPUs.

Thank you. C89 is definitely of interest to me, since one of the projects I code for is written in that dialect. — Charles, Apr 28 '19 at 19:56

score 0 · Answer 7 · answered Sep 09 '10 at 17:40

I'm not sure if there are any compiler switches you can use to enforce uniform behavior for overflows in C/C++. Another option is to use the SafeInt<T> template. It's a cross platform C++ template that provides definitive overflow / underflow checks for all types of integer operations.

http://safeint.codeplex.com/

Integer overflow in C: standards and compilers

7 Answers7

Linked