If you wrote
a = 7 INTMAX_MIN;
you would expect to get a syntax error, because on the face of it that would be an illegal expression. And it will, because it expands to
a = 7 (-9223372036854775807LL);
which does indeed give you a syntax error. But without the parentheses it would expand to:
a = 7 -9223372036854775807LL;
which doesn't give you an error, despite being obviously not what you intended.
More generally, all of these defines give expansions for things that look like identifiers. In an arithmetic expression, an identifier is a "primary expression", but -9223372036854775807LL is not. However, a parenthesized expression is a "primary expression".
And that's the real reason. So that the macro expands what looks like a primary expression to something that is a primary expression. You will never be surprised by what happens. In programming, surprise is usually bad.
Usually it doesn't matter, but the people who wrote the defines don't want them to usually work. They want them to always work.
The trailing LL marks this integer literal as of type long long
, which is typically (and in this case is) 64 bits. Without the LL suffix, the literal could be interpreted as int, long int, or long long int, whichever is the first to support 64-bit values. Nailing down the type can be as important as nailing down the value.
It's a good practice to put parentheses on a macro with a integer constant and a unary operator like this:
#define BLA (-1)
as unary operators (-
here) don't have the highest precedence in C. Postfix operators have higher precedence than unary operators. Remember that C doesn't have negative constants, for example -1
is a constant expression preceded with the -
unary operator.
As an aside PC-Lint suggest parenthesizes in such macros:
(rule 973): parentheser #define N (-1) Unary operator in macro 'Symbol' not parenthesized -- A unary operator appearing in an expression-like macro was found to be not parenthesized. For example:
#define N -1
The user may prefer to parenthesize such things as:
#define N (-1)
This answer attempts to show why the LL
is needed. (It is not easy.)
Other answers have shown why parentheses are needed.
Let's code three macros, all are decimal constants.
#define MAXILL (9223372036854775807LL)
#define MAXIL (9223372036854775807L)
#define MAXI (9223372036854775807)
Even though MAXI
has no suffix, that does not make it type int
. MAXI
will have the first type it fits in, either int
, long
, long long
or an extended integer type.
Even though MAXIL
has the L
suffix, it will have the first type it fits in, either long
, long long
or an extended integer type.
Even though MAXILL
has the LL
suffix, it will have the first type it fits in, either long long
or an extended integer type.
In every case, the macros have the same value, but potentially different types.
See C11dr §6.4.4.1 5 for type determination.
Let's try printing them and have int
and long
are 32-bit and long long
and intmax_t
are 64.
printf("I %d %d %d", MAXI, MAXIL, MAXILL); //Error: type mismatch
printf("LI %ld %ld %ld", MAXI, MAXIL, MAXILL); //Error: type mismatch
printf("LLI %lld %lld %lld", MAXI, MAXIL, MAXILL); //Ok
All three in the last line are correct as all three macros are long long
, the preceding have type mis-matches between format specifier and the number.
If we have int
is 32-bit and long
, long long
and intmax_t
are 64, then the following are correct.
printf("LI %ld %ld", MAXI, MAXIL);
printf("LLI %lld", MAXILL);
The maximum width integer type has a format specifier of "%" PRIdMAX
. This macro cannot expand to "%ld"
and "%lld"
to accommodate MAXI, MAXIL, MAXILL
. It is set to "%lld"
and numbers related to intmax_t
need to have the same type. In this case, long long
and only form MAXILL
should be used.
Other implementations could have an extended integer type (like int128_t
), in which case an implementation specific suffix or some mechanism could be used.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With