Member Avatar for swapnaoe

Hi there,

Here's a basic question from the basics of C.
Woukd like to know the use of appending L or UL at the end of integer constant which is assigned to an unsigned int type variable. for eg: on a 32-bit machine

unsigned int i;
i= 543727232UL;

what way it is going to help?

Thanks
Swapna

  • 3 Contributors
  • 3 Replies
  • 206 Views
  • 14 Hours Discussion Span
  • Latest Post Latest Post by Adak

Dani AI

Generated

Short answer: the suffix tells the compiler the literal’s type, and that changes the type used for the arithmetic. That matters because if every operand is a (narrow) int the intermediate product can overflow before it’s stored; making one operand long or unsigned long forces the whole evaluation into that wider type so the product fits.

A few practical details that matter for portability and correctness:

  • Unsuffixed decimal literals are given the first of int, long, long long that can hold the value; octal/hex try int, unsigned int, long, unsigned long (and then the long long variants).
  • Suffix U forces unsigned, L forces long, LL forces long long; combinations like UL/ULL give unsigned long / unsigned long long.
  • Mixing signed and unsigned converts the signed operand to unsigned, which can change comparisons and results — be explicit if you care about sign. This is the root of the warning mentioned when assigning a larger literal to a smaller type.

Example that shows the evaluation difference:

int a = 30000, b = 2;
long r1 = a * b;    /* multiplication done as int -> may overflow on 16-bit int */
long r2 = a * 2L;   /* one operand is long -> multiplication done as long -> safe */

Best practices: make the intent explicit. For portable constants prefer fixed-width types from C99 (uint32_t/int32_t) or use casts/macros so the expression is evaluated at the width you expect. Parenthesize macro definitions and avoid relying on default widths of int on old targets. As pointed out, the suffix is basically a way to “tell” the compiler which type you want the literal to have; do that deliberately to avoid overflow and surprising signed/unsigned conversions.

Recommended Answers

All 3 Replies

Member Avatar for creeps

It actually explicitly states that the assignment to i is of unsigned long type. Given the piece of code you've posted above, if you use something like splint to check your code, you get a warning, stating that the assignment to i is of incompatible type.

There are few cases I can think of in which the suffix really is helpful, but I remember something about a floating-point constant being treated like a double by default, suffixing it with f making it of float type.

Edited by creeps because: n/a
Member Avatar for swapnaoe

Hi There,

I was going through C test by Nigel Jones. Its popular test, I am sure many of us are aware of. The first question is about defining a macro to get the number of seconds in a year and the supposedly right answer to this is:
#define SECONDS_YEAR 365*24*60*60UL

And thats when it got me inot thinking the real use of suffixing UL/L at the end of the constant. This is what Nigel Jones gives the reasoning:
"A realization that the expression will overflow an integer argument on a 16-bit
machine-hence the need for the L, telling the compiler to treat the variable as
a Long"

I am still wondering of its purpose.

Thanks
Swapna

Member Avatar for Adak

Picture how it works:
1) The pre processor substitutes the numbersUL, for the expression SECS IN YEAR.

2) Now the compiler comes along and see's the number, but what data type (size) should it be given?

General default is integer, which is not big enough on a 16 bit machine.

So the suffix L or UL, is a little "cheat" to tell the compiler "this value should be treated as a long or unsigned long".

It's the compilers version of "pillow talk", imo. ;)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.