From an Example
unsigned long x = 12345678UL
We have always learnt that the compiler needs to see only "long" in the above example to set 4 bytes (in 32 bit) of memory. The question is why is should we use L/UL in long constants even after declaring it to be a long.
When a suffix L or UL is not used, the compiler uses the first type that can contain the constant from a list (see details in C99 standard, clause 6.4.4:5. For a decimal constant, the list is int, long int, long long int).
As a consequence, most of the times, it is not necessary to use the suffix. It does not change the meaning of the program. It does not change the meaning of your example initialization of x for most architectures, although it would if you had chosen a number that could not be represented as a long long. See also codebauer's answer for an example where the U part of the suffix is necessary.
There are a couple of circumstances when the programmer may want to set the type of the constant explicitly. One example is when using a variadic function:
printf("%lld", 1LL); // correct, because 1LL has type long long
printf("%lld", 1); // undefined behavior, because 1 has type int
A common reason to use a suffix is ensuring that the result of a computation doesn't overflow. Two examples are:
long x = 10000L * 4096L;
unsigned long long y = 1ULL << 36;
In both examples, without suffixes, the constants would have type int and the computation would be made as int. In each example this incurs a risk of overflow. Using the suffixes means that the computation will be done in a larger type instead, which has sufficient range for the result.
As Lightness Races in Orbit puts it, the litteral's suffix comes before the assignment. In the two examples above, simply declaring x as long and y as unsigned long long is not enough to prevent the overflow in the computation of the expressions assigned to them.
Another example is the comparison x < 12U where variable x has type int. Without the U suffix, the compiler types the constant 12 as an int, and the comparison is therefore a comparison of signed ints.
int x = -3;
printf("%d\n", x < 12); // prints 1 because it's true that -3 < 12
With the U suffix, the comparison becomes a comparison of unsigned ints. “Usual arithmetic conversions” mean that -3 is converted to a large unsigned int:
printf("%d\n", x < 12U); // prints 0 because (unsigned int)-3 is large
In fact, the type of a constant may even change the result of an arithmetic computation, again because of the way “usual arithmetic conversions” work.
Note that, for decimal constants, the list of types suggested by C99 does not contain unsigned long long. In C90, the list ended with the largest standardized unsigned integer type at the time (which was unsigned long). A consequence was that the meaning of some programs was changed by adding the standard type long long to C99: the same constant that was typed as unsigned long in C90 could now be typed as a signed long long instead. I believe this is the reason why in C99, it was decided not to have unsigned long long in the list of types for decimal constants.
See this and this blog posts for an example.
#define MY_DEFINE 123456789UL and you use MY_DEFINE later in the code. Naturally, it doesn't have type associated with it so UL addition may be of little help here. –
Gallice 18446744073709551615 is treated as -1L on systems with a 64-bit long. You have to explicitly use UL. –
Servitude 1 << 36 is probably UB, 1ULL << 36 is safe. Perhaps worth to be added in the list of examples. –
Cicisbeo *_C macros in stdint.h in this answer as well. It's already quite verbose ;) E.g. UINT64_C(x) produces a literal of value x with the right suffix to make its type uint64_t - thus there is no need for specific prefixes for the stdint.h data types. –
Maldives _C macro. Thanks for your comment. –
Basipetal 2147483648 is not an int –
Basipetal 4294967299*2 is a well-defined expression, of type long or long long (long if long is 64-bit). On the other hand 2000000000*3 is an expression of type int that contains undefined behavior, because 2000000000 is typed as int and the multiplication overflows. It's a funny language. –
Basipetal Because numerical literals are of typicaly of type int. The UL/L tells the compiler that they are not of type int, e.g. assuming 32bit int and 64bit long
long i = 0xffff;
long j = 0xffffUL;
Here the values on the right must be converted to signed longs (32bit -> 64bit)
0xffff is an int with the value of 65,535. Assigning that to i is not an issue. 0xffffUL is an unsigned long with the value of 65,535. Assigning that to j is also not an issue. Had this example been long i = 0xffffffff; 0xffffffff is an unsigned with the value of 4,294,967,295 and assigning that to 64-long is not an issue. Also a non-issue with long j = 0xffffffffUL; This answer's #1 "converted to a long using sign extension" is not true here. –
Blanding The question is why is should we use L/UL in long constants even after declaring it to be a long.
Because it's not "after"; it's "before".
First you have the literal, then it is converted to whatever the type is of the variable you're trying to squeeze it into.
They are two objects. The type of the target is designated by the unsigned long keywords, as you've said. The type of the source is designated by this suffix because that's the only way to specify the type of a literal.
LUL instead of ULL :) –
Oslo Related to this post is why a u.
A reason for u is to allow an integer constant greater than LLONG_MAX in decimal form.
// Likely to generate a warning.
unsigned long long limit63bit = 18446744073709551615; // 2^64 - 1
// OK
unsigned long long limit63bit = 18446744073709551615u;
© 2022 - 2024 — McMap. All rights reserved.
ULis used instead ofLor instead of nothing? – Servitude