So many parentheses in gcc standard headers

Question

Why are constant expressions in GCC header files surrounded by parentheses, like this?

#define INTMAX_MIN (-9223372036854775807LL)
#define INTMAX_MAX (9223372036854775807LL)

What would be the difference if I omit parentheses, this way?

#define INTMAX_MIN -9223372036854775807LL
#define INTMAX_MAX 9223372036854775807LL

And why is there the 'L' suffix? Would it be the very same if I write the following?

#define INTMAX_MIN -9223372036854775807
#define INTMAX_MAX 9223372036854775807

Is there an actual usefulness or is it always the same thing?

I'm aware that the 'L' stands for long and I'm also well aware of the importance of parentheses in C macros; I'm asking this for the sake of curiosity.

score 83 · Accepted Answer · edited Dec 27 '14 at 08:02

83

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.

edited Dec 27 '14 at 08:02

Rufflewind

8,545
2
35
55

answered Dec 27 '14 at 02:39

ganbustein

1,593
11
10

10

You might also discuss `a = 7-INT_MAX;` with and without parentheses around `INT_MAX`, noting that the result would be different from `a = 7 - INT_MAX;`. – Jonathan Leffler Dec 27 '14 at 02:41
@JonathanLeffler How would the result be different? You shouldn't need parentheses for `INT_MAX` since an integer literal is a primary expression. – Eric M Schmidt Dec 27 '14 at 05:11
3

@EricMSchmidt: _…blah, blah…_ **…Unless…** Oh drat! The original separate preprocessor process tended to give one answer, but the modern (as in 1989 or later) version tokenizes the input and the input stays tokenized, so `#define X -7` and `int main(void) { int x = 7-X; return x; }` yields a program that exits with status 14. I should have remembered. – Jonathan Leffler Dec 27 '14 at 05:27
1

"the literal would be interpreted as an ordinary integer" is incorrect as @mafso comments. Try `printf("%zu\n", sizeof (9223372036854775807));` – chux - Reinstate Monica Dec 27 '14 at 06:38
1

@mafso: That's not entirely correct from the language point of view. The only standard version of C language that allowed using *unsigned* types for suffix-less constants was C89/90. This functionality was outlawed in C99. Suffix-less constants can only have *signed* types. If the constant does not fit into the largest signed type the behavior is undefined. I.e. the language does not support using `unsigned long long` for a suffix-less constant. – AnT stands with Russia Dec 27 '14 at 07:32
@AndreyT mafso comment is good if we strike the the "`unsigned long long`" and use "Without the suffix, the type of the integer literal is the first of `int`, `long`, `long long`, which can hold the value." Having an "extended integer type" is another consideration. BTW: it is "Suffix-less _decimal_ constants that must be signed. – chux - Reinstate Monica Dec 27 '14 at 07:35
here is the practical reason to place parens around parameters in #define macros: given: #define number(x,y) x*x+y*y Then the actual invocation of the macros is int result = number(10+20,5+6); which expands to: result = 10+20*10+20+5+6*5+6; which is obviously not correct. However, if parens are used: #define number(x,y) (x)*(x)+(y)*(y) then it would expand to (10+20)*(10+20)+(5+6)*(5+6) which is correct. This kind of problem occurs often in real programing and is the reason for the parens – user3629249 Dec 27 '14 at 09:30
@JonathanLeffler can you elaborate why `a = 7-INT_MAX;` and `a = 7 - INT_MAX;` return different results? – phuclv Dec 27 '14 at 13:15
@LưuVĩnhPhúc: I retracted that claim with my response comment to Eric Schmidt. – Jonathan Leffler Dec 27 '14 at 16:08

score 18 · Answer 2 · edited Dec 27 '14 at 16:18

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)

score 12 · Answer 3 · edited Dec 27 '14 at 13:10

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.

As a note, with C11 `_Generic` (and before with the popular `typeof` extension) types have become easier observable. (In C99 without extensions, I don't know how the difference between `long` and `long long` could be observed if they have the same size and representation; given that it's OK if the implementation makes assumptions about calling conventions, and that it's quite unlikely that `long` and `long long` are passed differently, the question if the suffix is really needed for strict C99 remains.) — mafso, Dec 27 '14 at 08:11

So many parentheses in gcc standard headers

3 Answers3