Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

On most platforms, long and int are the same size (32 bits). Still, it does have its own format specifier:

long n;
unsigned long un;
printf("%ld", n); // signed
printf("%lu", un); // unsigned
For 64 bits, you'd want a long long:
long long n;
unsigned long long un;
printf("%lld", n); // signed
printf("%llu", un); // unsigned
Oh, and of course, it's different in Windows:
printf("%l64d", n); // signed
printf("%l64u", un); // unsigned
Frequently, when I'm printing 64-bit values, I find it helpful to print them in hex (usually with numbers that big, they are pointers or bit fields).
unsigned long long n;
printf("0x%016llX", n); // "0x" followed by "0-padded", "16 char wide", "long long", "HEX with 0-9A-F"
will print:
0x00000000DEADBEEF
Btw, "long" doesn't mean that much anymore (on mainstream x64).  "int" is the platform default int size, typically 32 bits.  "long" is usually the same size.  However, they have different portability semantics on older platforms (and modern embedded platforms!).  "long long" is a 64-bit number and usually what people meant to use unless they really really knew what they were doing editing a piece of x-platform portable code.  Even then, they probably would have used a macro instead to capture the semantic meaning of the type (eg uint64_t).
char c;       // 8 bits
short s;      // 16 bits
int i;        // 32 bits (on modern platforms)
long l;       // 32 bits
long long ll; // 64 bits 
Back in the day, "int" was 16 bits.  You'd think it would now be 64 bits, but no, that would have caused insane portability issues.  Of course, even this is a simplification of the arcane and history-rich truth.  See wiki:Integer
                Just to clarify: there are more architectures than x86 and x64, and on those architectures, char, short, int, long and long long have different meanings. For example, a 32 bit mcu with 16 bit memory alignment could use: char=short=int=16 bit; long=32 bits; long long = 64 bits
– AndresR
                Sep 6, 2016 at 19:19
                @AndresR - absolutely, and it matters very deeply to people who do embedded programming (I built a kernel module for a smoke alarm once). Pity those poor souls when they try to use code that wasn't written for portability.
– Dave Dopson
                Sep 7, 2016 at 19:44
                I'm not so sure that "most platforms have a long that's of size 32" is still true.  E.g., I'm on Oracle Linux x86_64/amd64, and with nvcc a long is 8 bytes.
– interestedparty333
                Jun 17, 2019 at 18:02
                @interestedparty333 Yes, I'm >95% sure that in Linux long has the same size as the word/pointer size (so 32-bits on 32-bit Linux and 64-bits on 64-bit Linux). If you look inside the Linux kernel's code or inside Linux drivers, they usually store pointers in long or unsigned long variables. Actually, a few weeks ago a colleague of mine who ported some code from Windows to Linux had to go and change all our longs to uint32_t because we would constantly misuse them when developing under Windows.
– adentinger
                Feb 19, 2021 at 22:21
I needed to print unsigned long long, so I found this works:
unsigned long long n;
printf("%llu", n);
For all other combinations, I believe you use the table from the printf manual, taking the row, then column label for whatever type you're trying to print (as I do with printf("%llu", n) above).
                No: there is no platform dependency on the correct format for printing a long — the correct answer is %ld.  The range of values that may be printed does depend on the platform — on some platforms long will be a 32-bit type (especially back in 2008) and on other platforms it will be a 64-bit type (especially in 2022 and later).  But if the data type is long, the correct printf() conversion specifier is %ld (though you can use %li).
– Jonathan Leffler
                Nov 4, 2022 at 21:00