21

I have a pretty basic question, but I am not sure if I understand the concept or not. Suppose we have:

int a = 1000000;
int b = 1000000;
long long c = a * b;

When I run this, c shows negative value, so I changed also a and b to long long and then everything was fine. So why do I have to change a and b, when their values are in range of int and their product is assigned to c (which is long long)?

I am using C/C++

JFMR
  • 23,265
  • 4
  • 52
  • 76
essa
  • 213
  • 1
  • 2
  • 6
  • 24
    The ints are not promoted to long long before multiplication, they remain ints and the product as well. Then the product is cast to long long, but too late, overflow has struck. Having one of a or b long long should work as well, as the other would be promoted. –  Jul 27 '15 at 20:39
  • You should tag the programing language you're using cause different languages might introduce different behavior ;) – Nir Alfasi Jul 27 '15 at 20:42
  • Depending on which machine and version of C you're using the size of an 'int' may change as well. – Jay Jul 27 '15 at 20:48
  • @YvesDaoust - you should make it all official and stuff and copy/paste that into an answer rather than have it slumming it out as a comment. :) – Jim Buck Jul 27 '15 at 20:55
  • @JimBuck: why not ?:-) –  Jul 27 '15 at 21:05
  • 1
    long long c = ((long long)a*(long long)b); –  Jul 27 '15 at 21:06
  • long long c=(long long)a*b – ggrr Jul 28 '15 at 01:45
  • @danludwig I usually prefer not to add tags in titles but it is [debatable](http://meta.stackoverflow.com/q/253028/1708801) – Shafik Yaghmour Jul 28 '15 at 02:00
  • 1
    This is a duplicate of one of my earlier questions http://stackoverflow.com/questions/29579112/how-to-write-int64-int32int32-in-a-standard-portable-and-efficient-way – user3528438 Jul 29 '15 at 14:54
  • In C++11 (or later) you can declare `c` to be of "type" `auto` and this will solve this issue, meaning: `auto c = a*b;` will assign the right value to `c`. – Guy Avraham Jan 02 '22 at 09:36

3 Answers3

28

The ints are not promoted to long long before multiplication, they remain ints and the product as well. Then the product is cast to long long, but too late, overflow has struck.

Having one of a or b long long should work as well, as the other would be promoted.

4

For arithmetic operators the type of the result is not dependent on what you are assigning the result to but the types of the operands. For arithmetic operators the usual arithmetic conversions are performed on the operands. This is used to bring the operands to a common type, this means for types smaller than unsigned/signed int if the values can fit they are promoted to unsigned/signed int, in this case they are already both int so no conversion is required. See Why must a short be converted to an int before arithmetic operations in C and C++? for the details on why.

What we have now is undefined behavior since signed integer overflow is undefined behavior, this is covered in the draft C++ standard section 5 [Expr] which says:

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. —end note ]

Now-a-days we have sanitizers to catch these types of undefined behavior and using -fsanitize=undefined with both clang and gcc will catch this at runtime with the following error (see it live):

runtime error: signed integer overflow: 1000000 * 1000000 cannot be represented in type 'int'

For reference section 5.6 [expr.mul] says:

[...]The usual arithmetic conversions are performed on the operands and determine the type of the result.

and section 5 says:

Otherwise, the integral promotions (4.5) shall be performed on both operands.61 Then the following rules shall be applied to the promoted operands

  • If both operands have the same type, no further conversion is needed.
Community
  • 1
  • 1
Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
2

It's kind of absurd, because the assembler instruction does always compute

int * int -> 64 bits long

so if you look at the machine code, you see : imul that store 64bits into eax edx then cdq that put the bit sign of eax into edx (thus losing the full 64bits result) and then eax edx are stored into the 64bits variable

and if you convert the 32bits values into 64bits before the multiplication, you get a call to the 64bits multiplication function for no reason

(I checked : it's not the case when the code is optimized)

Edgard Neuman
  • 21
  • 4
  • 1
    I agree 100%. I learned about the integer promotion rules on my first job in 1992, and still this behavior of C/C++ trips me up sometimes. FWIW, ARM assembler behaves similarly to the Intel assembly behavior you described. Multiplying 2 32-bit operands works fine when the destination is 64 bits. It is just the language rules that destroy the math. – Erik Alapää Jun 02 '19 at 06:52