Suffix for a intmax_t literal

Question

There doesn't seem to be a 'J' suffix (a la printf's %jd).

So, is it guaranteed that the LL and ULL suffixes are going to work with intmax_t and uintmax_t types?

#include <stdint.h>

intmax_t yuuge = 123456789101112131411516LL;

or is it possible that there are literals that are too big for the LL suffix? Say, a (hypothetical) system with 32 bit int, 32 bit long, 64 bit long long, 128 bit intmax_t.

Detail: In C `123` is specified as a _constant_, not a _literal_. C has 2 literals: _string literal_ and _compound literal_. Both can have their address taken. Code cannot take the address of `123`. Other languages do allow that though. — chux - Reinstate Monica, Apr 12 '18 at 16:52

score 6 · Answer 1 · answered Apr 12 '18 at 16:19

No suffix is needed if you just want the value to be faithfully represented. The C language automatically gives integer literals the right type. Suffixes are only needed if you want to force a literal to have higher-rank type than it would naturally have due to its value (e.g. 1UL to get the value 1 as unsigned long rather than int, or -1UL as an alternate expression for ULONG_MAX).

If you do want to force a literal to have type intmax_t, use the INTMAX_C() macro from stdint.h.

score 2 · Accepted Answer · edited Jun 20 '20 at 09:12

it possible that there are literals that are too big for the LL suffix

Yes, if the integer constant exceeds the range of (u)intmax_t, it is too big, with or without the LL.

See Assigning 128 bit integer in C for a similar problem.

LL and LLU are not for types. They are for integer constants.

An L or LL insures the minimum type of a constant. The is no suffix for intmax_t.

123 is an `int`
123L is a `long`
123LL is a `long long`
123456789012345 is a `long long` on OP's hypothetical system even without LL

intmax_t may have the same range as long long - or it may be wider. Both intmax_t and long long are at least 64-bit.

With a well warning enabled compiler, should the constant exceed the intmax_t range, a warning would occur. Examples:

//  warning: integer overflow in expression
intmax_t yuuge1 = (intmax_t)123456*1000000000000000000 + 789101112131411516;

//  warning: overflow in implicit constant conversion [-Woverflow]
intmax_t yuuge2 = 123456789101112131411516;

C provides macros for greatest-width integer constants

The following macro expands to an integer constant expression having the value specified by its argument and the type intmax_t: C11 §7.20.4.2 1
INTMAX_C(value)

The INTMAX_C(value) does have a limitation

The argument in any instance of these macros shall be an unsuffixed integer constant ... with a value that does not exceed the limits for the corresponding type.

The following does not meet that requirement on machines with with 64-bit intmax_t.

// Not so portable code
intmax_t yuuge = INTMAX_C(123456789101112131411516);

# pre-processing is also limited to intmax_t.

Code that attempts to create a constant outside the (u)int64_t range can easily have portability problems. For portability, another coding approach is advised (Avoid such large constants).

Suffix for a intmax_t literal

2 Answers2