Why does long long n = 2000*2000*2000*2000; overflow?

Question

Because 2000 is an int which is usually 32-bit. Just use 2000LL.

Using LL suffix instead of ll was suggested by @AdrianMole in, now deleted, comment. Please check his answer.

By default, integer literals are of the smallest type that can hold their value but not smaller than int. 2000 can easily be stored in an int since the Standard guarantees it is effectively at least a 16-bit type.

Arithmetic operators are always called with the larger of the types present but not smaller than int:

• char*char will be promoted to operator*(int,int)->int
• char*int calls operator*(int,int)->int
• long*int calls operator*(long,long)->long
• int*int still calls operator*(int,int)->int.

Crucially, the type is not dependent on whether the result can be stored in the inferred type. Which is exactly the problem happening in your case - multiplication is done with ints but the result overflows as it is still stored as int.

C++ does not support inferring types based on their destination like Haskell does so the assignment is irrelevant.

The constants (literals) on the RHS of your first line of code are int values (not long long int). Thus, the mulitplications are performed using int arithmetic, which will overflow.

To fix this, make the constants long long using the LL suffix:

long long int n = 2000LL * 2000LL * 2000LL * 2000LL;

cppreference

In fact, as noted in the comment by Peter Cordes, the LL suffix is only actually needed on either the first (leftmost) or second constant. This is because, when multiplying types of two different ranks, the operand of lower rank is promoted to the type of the higher rank, as described here: Implicit type conversion rules in C++ operators. Furthermore, as the * (multiplication) operator has left-to-right associativity, the 'promoted' result of the first multiplication propagates that promotion to the second and third.

Thus, either of the following lines will also work without overflow:

long long int n1 = 2000LL * 2000 * 2000 * 2000;
long long int n2 = 2000 * 2000LL * 2000 * 2000;

---

Note: Although lowercase suffixes (as in 2000ll) are valid C++, and entirely unambiguous to the compiler, there is a general consensus that the lowercase letter, 'ell', should be avoided in long and long long integer literals, as it can easily be mistaken, by human readers, for the digit, 1. Thus, you will notice that 2000LL (uppercase suffix) has been used throughout the answers here presented.

2000*2000*2000*2000 is a multiplication of 4 int values, which returns an int value. When you assign this int value to long long int n the overflow already happend (if int is 32 bit the resulting value won't fit).

You need to make sure that the overflow does not occur, so when you write

long long int n = static_cast<long long int>(2000)*2000*2000*2000;

you make sure that you are doing a long long int multiplication (long long int multiplied with int returns a long long int, so no overflow in your case).

A shorter (and better way) is to write 2000LL or 2000ll instead of the static_cast. That gives the integer literal the right type. This is not needed for 2000 which fits into an int but it would be needed for higher values that don't fit into an int.

long long int n = 2000LL*2000*2000*2000;
long long int n = 2000LL*2000LL*2000LL*2000LL;

The other answers (as of this writing) appear to not have been explicit enough to answer the question as stated. I'll try to fill this gap.

Why does the first one overflow (multiplying integer literal constants to assign to a long long)?

The expression

long long int n = 2000*2000*2000*2000;

is evaluated as follows:

long long int n = ((2000*2000)*2000)*2000;

where the steps are (assuming 32-bit int):

1. (2000*2000) is a multiplication of two int values that yields 4000000, another int value.
2. ((2000*2000)*2000) is a multiplication of the above yielded int value 4000000 with an int value 2000. This would yield 8000000000 if the value could fit into an int. But our assumed 32-bit int can store a maximum value of 2³¹-1=2147483647. So we get overflow right at this point.
3. The next multiplication would happen if there hadn't been overflow above.
4. The assignment of the resulting int product would happen (if not the overflow) to the long long variable, which would preserve the value.

Since we did have overflow, the statement has undefined behavior, so steps 3 and 4 can't be guaranteed.

What's different about it vs. the second or third ones?

• long long int n = pow(2000,4);

The pow(2000,4) converts 2000 and 4 into double (see some docs on pow), and then the function implementation does its best to produce a good approximation of the result, as a double. Then the assignment converts this double value to long long.

• long long int n = 16000000000000;

The literal 16000000000000 is too large to fit into an int, so its type is instead the next signed type that can fit the value. It could be long or long long, depending on the platform. See Integer literal#The type of the literal for details. then the assignment converts this value to long long (or just writes it, if the literal's type was long long already).

The first is a multiplication using integers (typically 32 bit). It overflows because those integers cannot store 2000^4. The result is then cast to long long int.

The second calls the pow function which casts the first argument to double and returns a double. The result is then cast to long long int. There is no overflow in this case because the math is done on a double value.

You might want to use the following in C++ to understand this:

#include<iostream>
#include<cxxabi.h>

using namespace std;
using namespace abi;

int main () {
    int status;
    cout << __cxa_demangle(typeid(2000*2000*2000*2000).name(),0,0,&status);
}

As you can see, the type is int.

In C, you can use (courtesy of):

#include <stdio.h>
#include <stddef.h>
#include <stdint.h>

#define typename(x) _Generic((x),        /* Get the name of a type */             \
                                                                                  \
        _Bool: "_Bool",                  unsigned char: "unsigned char",          \
         char: "char",                     signed char: "signed char",            \
    short int: "short int",         unsigned short int: "unsigned short int",     \
          int: "int",                     unsigned int: "unsigned int",           \
     long int: "long int",           unsigned long int: "unsigned long int",      \
long long int: "long long int", unsigned long long int: "unsigned long long int", \
        float: "float",                         double: "double",                 \
  long double: "long double",                   char *: "pointer to char",        \
       void *: "pointer to void",                int *: "pointer to int",         \
       char(*)[]: "pointer to char array",      default: "other")


unsigned int a = 3;
int main() {
    printf("%s", typename(a-10));
    return 0;
}

Here the type of the expression is unsigned int because the type mismatch implicitly upgrades the type to the largest type between unsigned int and int, which is unsigned int. The unsigned int will underflow to a large positive, which will be the expected negative when assigned to or interpreted as an int. The result of the calculation will always be unsigned int regardless of the values involved.

C

The minimum default type of an integer literal without a suffix is int, but only if the literal exceeds this, does its type becomes an unsigned int; if larger than that it is given a type of a long int, therefore 2000s are all ints. The type of an expression performed on a literal however, using unary or binary operators, uses the implicit type hierarchy to decide a type, not the value of the result (unlike the literal itself which uses the length of the literal in deciding the type), this is because C uses type coercion and not type synthesis. In order to solve this, you'd have to use long suffixes ul on the 2000s to explicitly specify the type of the literal.

Similarly, the default type of a decimal literal is double, but this can be changed with a f suffix. Prefixes do not change the type of decimal or integer literals.

The type of a string literal is char [], although it is really a const char [], and is just an address of the first character in the actual representation of that string literal in .rodata, and the address can be taken like any array using the unary ampersand &"string", which is the same value (address) as "string", just a different type (char (*)[7] vs. char[7]; "string" i.e. char[] is not just (at compiler level) a pointer to the array, it is the array, whereas the unary ampersand extracts just the pointer to the array). The u prefix changes this to an array of char16_t, which is an unsigned short int; the U prefix changes it to an array of char32_t, which is an unsigned int; and the L prefix changes it to an array of wchar_t which is an int. u8 is a char and an unprefixed string uses implementation specific encoding, which is typically the same as u8 i.e. UTF-8, of which ASCII is a subset. A raw (R) prefix available only for string literals (and available only on GNU C (std=gnu99 onwards)) can be prefixed i.e. uR or u8R, but this does not influence the type.

The type of a character literal is int unless prefixed with u (u'a' is unsigned short int) or U (U'a' is unsigned int). u8 and and L are both int when used on a character literal. An escape sequence in a string or character literal does not influence the encoding and hence the type, it's just a way of actually presenting the character to be encoded to the compiler.

The type of a complex literal 10i+1 or 10j+1 is complex int, where both the real and the imaginary part can have a suffix, like 10Li+1, which in this case makes the imaginary part long and the overall type is complex long int, and upgrades the type of both the real and the imaginary part, so it doesn't matter where you put the suffix or whether you put it on both. A mismatch will always use the largest of the two suffixes as the overall type.

Using an explicit cast instead of a literal suffix always results in the correct behaviour if you use it correctly and are aware of the semantic difference that it truncates/extends (sign extends for signed; zero extends for unsigned – this is based on the type of the literal or expression being cast and not the type that's being cast to, so a signed int is sign extended into an unsigned long int) a literal to an expression of that type, rather than the literal inherently having that type.

C++

Again, the minimum default type is an int for the smallest literal base. The literal base i.e. the actual value of the literal, and the suffix influence the final literal type according to the following table where within each box for each suffix, the order of final type is listed from smallest to largest based on the size of the actual literal base. For each suffix, the final type of the literal can only be equal to or larger than the suffix type, and based on the size of the literal base. C exhibits the same behaviour. When larger than a long long int, depending on the compiler, __int128 is used. I think you could also create your own literal suffix operator i128 and return a value of that type.

The default type of a decimal literal is the same as C.

The type of a string literal is char []. The type of &"string" is const char (*) [7] and the type of +"string" is const char * (in C you can only decay using "string"+0). C++ differs in that the latter 2 forms acquire a const but in C they don't. The string prefixes behave the same as in C

Character and complex literals behave the same as C.