Related
long long int n = 2000*2000*2000*2000; // overflow
long long int n = pow(2000,4); // works
long long int n = 16000000000000; // works
Why does the first one overflow (multiplying integer literal constants to assign to a long long)?
What's different about it vs. the second or third ones?
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):
(2000*2000) is a multiplication of two int values that yields 4000000, another int value.
((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 231-1=2147483647. So we get overflow right at this point.
The next multiplication would happen if there hadn't been overflow above.
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.
long long int n = 2000*2000*2000*2000; // overflow
long long int n = pow(2000,4); // works
long long int n = 16000000000000; // works
Why does the first one overflow (multiplying integer literal constants to assign to a long long)?
What's different about it vs. the second or third ones?
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):
(2000*2000) is a multiplication of two int values that yields 4000000, another int value.
((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 231-1=2147483647. So we get overflow right at this point.
The next multiplication would happen if there hadn't been overflow above.
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.
What are the rules used by C++ to determine the type of an arithmetic expression involving two different integer types?
In general it is easy to work out the outcome, however I have come across cases with signed/unsigned ints that are confusing.
For example both the below come out as unsigned int in VS.
unsigned int us = 0;
int s = 1;
auto result0 = us - s; // unsigned int
auto result1 = s - us; // unsigned int
Is this the same for other compilers? Are there any specific rules for determining the type?
It's all well-defined.
1 is a signed literal. In fact, if you wanted it unsigned, you'd need to use hexadecimal or octal notation, an appropriate suffix (for example u), or a cast.
If an arithmetic operation is encountered that has a signed int and an unsigned int as arguments, then the signed int is converted to an unsigned int type.
Here is a short, rough answer, I hope it is useful even though it does not cover everything and may even be an oversimplification:
Literals are signed unless specified as 'U'.
In an integral expressions involving different types, the smaller integer types are promoted (to int if all involved types would fit in int, otherwise promotion to unsigned int), so when an unsigned and a signed value e.g. are added, the signed value is 'promoted' to unsigned int if the unsigned variable is of same bit width as an int. So an unsigned int is regarded by the compiler as 'larger' than a signed int in the promotion rules, even if during runtime the actual values stored in the variables would easily fit into a signed representation of same number of bits.
Note also that 'char' may mean unsigned char, while 'int' always means signed int.
To give a little background (unrelated to the question, which will follow), in C++11 I noticed a narrowing issue:
int foo[] = { 0xFFFFFFFF };
This was failing to compile (narrowing conversion) because 0xFFFFFFFF is an unsigned int. However, I've seen cases where 0xFF is signed.
I've looked over integer promotion rules, but this is mostly within the context of lvalues and not rvalues/constants. How does the compiler determine the type of constants (without literal suffixes)? Is there documentation or a nice little table / "cheat sheet" that shows the rules for this? I'm not even really sure what this is called, otherwise I'd have attempted to find it myself in the C++11 standard.
Thanks in advance.
There's a table in the standard, which is reproduced on cppreference.com: http://en.cppreference.com/w/cpp/language/integer_literal
In particular, a hex or octal integer literal with no suffix is considered to have the first type in the following list in which its value can be represented:
int
unsigned int
long int
unsigned long int
long long int
unsigned long long int
0xFFFFFFFF is too big for int if int is 32 bits long, so unsigned int is chosen. But 0xFF fits comfortably into an int, so int it is.
What are called referred to as Integer constants in C are referred to as integer literals in C++. The rules used to determine the type of an integer literal are covered in the draft C++ standard section 2.14.2 Integer literals table 6 which says:
The type of an integer literal is the first of the corresponding list
in Table 6 in which its value can be represented.
and for Octal or hexadecimal constant with no suffix the table has the following order:
int
unsigned int
long int
unsigned long int
long long int
unsigned long long int
So 0xFF can be represented as an int while the first type that can represent 0xFFFFFFFF would be unsigned int.
The order for Decimal Constants is as follows:
int
long int
long long int
As we can see hexidecimal and octal literals behave differently, and we can see that C99 has the same table. The Rationale for International Standard—Programming Languages—C says the following about this:
Unlike decimal constants, octal and hexadecimal constants too large to
be ints are typed as unsigned int if within range of that type, since
it is more likely that they represent bit patterns or masks, which are
generally best treated as unsigned, rather than “real” numbers.
cppreference integer literal section also quotes table 6 in the The type of the literal sub-section.
0xFF is never negative. It is an alternative way of writing 255. (It has type int).
0xFFFFFFFF is a large positive number. There is a table under [lex.icon] that specifies what the type is of an integer constant. For hex constants with no suffix, it is the first type in the following list that can hold that large positive number: int, unsigned int, long int, unsigned long int, long long int, unsigned long long int. The implementation might add custom types ot this list.
I can't find the exact specification of how int value is converted to unsigned long long in the standard. Various similar conversions, such as int -> unsigned, unsigned -> int (UB if negative), unsigned long long -> int, etc. are specified
For example GCC, -1 is converted to 0xffffffffffffffff, not to 0x00000000ffffffff. Can I rely on this behavior?
Yes, this is well defined, it is basically adding max unsigned long long + 1 to -1 which will always be max unsigned long long. This is covered in the draft C++ standard section 4.7 Integral conversions which says:
If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type). [ Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). —end note ]
it does the same thing as C99 but the draft C99 standard is easier to understand, from section 6.3.1.3 Signed and unsigned integers:
Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or
subtracting one more than the maximum value that can be represented in the new type
until the value is in the range of the new type.49)
where footnote 49 says:
The rules describe arithmetic on the mathematical value, not the value of a given type of expression.
Yes, it's defined:
C++11 § 4.7 [conv.integral]/2 says this:
If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type).
The least unsigned integer congruent to -1 (modulo 2sizeof(unsigned long long)) is the largest value of unsigned long long possible.
Unsigned integers have guaranteed modulo arithmetic. Thus any int value v is converted to the unsigned long value u such that u = K*2n+v, where K is either 0 or 1, and where n is the number of value representation bits for unsigned long. In other words, if v is negative, just add 2n.
The power of 2 follows from the C++ standard's requirement that integers be represented with a pure binary system. With n value representation bits the number of possible values is 2n. There is not such a requirement for floating point types (you can use std::numeric_limits to check the radix of the representation of floating point values).
Also note that in order to cater to some now archaic platforms, as well as one popular compiler that does things its own way, the standard leaves the opposite conversion as undefined behavior when the unsigned value is not directly representable as a signed value. In practice, on modern systems all compilers can be told to make that reverse conversion the exact opposite of the conversion to unsigned type, and e.g. Visual C++ does that by default. However, it's worth keeping in mind that there's no formal support, so that portable code incurs a slight (now with modern computers needless) inefficiency.