What is the bit size of long on 64-bit Windows?

Question

Not to long ago, someone told me that long are not 64 bits on 64 bit machines and I should always use int. This did not make sense to me. I have seen docs (such as the one on Apple's official site) say that long are indeed 64 bits when compiling for a 64-bit CPU. I looked up what it was on 64-bit Windows and found

• Windows: long and int remain 32-bit in length, and special new data types are defined for 64-bit integers.

(from http://www.intel.com/cd/ids/developer/asmo-na/eng/197664.htm?page=2)

What should I use? Should I define something like uw, sw ((un)signed width) as a long if not on Windows, and otherwise do a check on the target CPU bitsize?

Incandesce

On Windows with MSVC++ int and long are 32-bit: msdn.microsoft.com/en-us/library/3b2e7499.aspx . However, to allow e.g. vectors to store more than 4G of items, size_t is 64 bit. So one needs to use int64_t instead of int to iterate e.g. vectors which may contain more than 4G items. – Undermanned

In Cygwin sizeof(long) == 8, even on Windows :-) – Immingle

@SergeRogatch they should use size_t or an iterator type to iterate, not int or int64_t – Melburn

@LưuVĩnhPhúc, with size_t it becomes tricky near negative numbers, because size_t is unsigned. So for(size_t i=0; i<v.size()-2; i++) fails for vector size 0 and 1. Another example: for(size_t i=v.size()-1; i>=0; i--). – Undermanned

If you are doing maths on pointers (i.e. with size_t values then the result should be kept in a variable of ptrdiff_t type - which is designed to be large enough to hold such a result and is a signed type for precisely that reason!) – Superhighway

@Immingle this is about compilers, not operating systems. Cygwin is compiled using mingw (A GCC port to windows) as its compiler. Like GCC on linux, it can define long as 64 bits, however MSVC++ (the microsoft compiler) defines it as 32 bits – Corry

@OrionEdwards Actually it's about the target platform ABI. Cygwin has it's own POSIX-like ABI and chooses the more POSIX-friendly LLP64 model, whereas Mingw sticks to the Win32 ABI with its LP64 model. For this reason in GCC bundled with Mingw long is 32 bits and in GCC in Cygwin - 64 bits. – Immingle

@Immingle I feel like we're talking past eachother. My point is that long exists only in the world of the compiler, and the conventions it expects. Once it actually comes to running code, it's just "There are 8 bytes at this address", and the terms int, long, etc don't exist – Corry

Answer 1

In the Unix world, there were a few possible arrangements for the sizes of integers and pointers for 64-bit platforms. The two mostly widely used were ILP64 (actually, only a very few examples of this; Cray was one such) and LP64 (for almost everything else). The acronynms come from 'int, long, pointers are 64-bit' and 'long, pointers are 64-bit'.

Type           ILP64   LP64   LLP64
char              8      8       8
short            16     16      16
int              64     32      32
long             64     64      32
long long        64     64      64
pointer          64     64      64

The ILP64 system was abandoned in favour of LP64 (that is, almost all later entrants used LP64, based on the recommendations of the Aspen group; only systems with a long heritage of 64-bit operation use a different scheme). All modern 64-bit Unix systems use LP64. MacOS X and Linux are both modern 64-bit systems.

Microsoft uses a different scheme for transitioning to 64-bit: LLP64 ('long long, pointers are 64-bit'). This has the merit of meaning that 32-bit software can be recompiled without change. It has the demerit of being different from what everyone else does, and also requires code to be revised to exploit 64-bit capacities. There always was revision necessary; it was just a different set of revisions from the ones needed on Unix platforms.

If you design your software around platform-neutral integer type names, probably using the C99 <inttypes.h> header, which, when the types are available on the platform, provides, in signed (listed) and unsigned (not listed; prefix with 'u'):

• int8_t - 8-bit integers
• int16_t - 16-bit integers
• int32_t - 32-bit integers
• int64_t - 64-bit integers
• uintptr_t - unsigned integers big enough to hold pointers
• intmax_t - biggest size of integer on the platform (might be larger than int64_t)

You can then code your application using these types where it matters, and being very careful with system types (which might be different). There is an intptr_t type - a signed integer type for holding pointers; you should plan on not using it, or only using it as the result of a subtraction of two uintptr_t values (ptrdiff_t).

But, as the question points out (in disbelief), there are different systems for the sizes of the integer data types on 64-bit machines. Get used to it; the world isn't going to change.

Smalt

For those of use who've been around long enough, the 64-bit transition has some parallels with the 16-bit to 32-bit transition of the mid-80s. There were computers that were IL32 and others that were L32 (adapting the new notation to the old problem). Sometimes 'int' was 16-bit, sometimes 32-bit. – Smalt

Don't forget that this only applies to C-ish languages. Others have saner specifications where a) the compiler writer is not allowed to choose the size of the datatypes willi-nilly or b) the physical representation of the datatypes doesn't "leak" or c) integers are always infinitely large. – Resultant

True - but for those languages which specify the behaviour, there isn't an issue in the first place. For example, Java has a 'long', but the size is fixed (64-bit?), on all platforms. So, there are no issues porting to a 64-bit machine; the size does not change. – Smalt

Claiming that Alpha was/is ILP64 is wrong. OpenVMS, Tru64 and Linux running on Alpha are all "just" LP64. – Gnomon

@Daniel: thanks for the correction - I've updated the answer more or less appropriately. – Smalt

you think ILP64 would be more popular, wouldn't it be easier to process a 64bit data type on a 64 bit cpu? – Arnoldoarnon

@TomFobear: ILP64 presents one major issue - what do you call the 32-bit type? Or, if you call the 32-bit type short, what do you call the 16-bit type? And if you call the 16-bit type char for UTF-16 etc, what do you call the 8-bit type? So, using LP64 leaves you with 8-bit char, 16-bit short, 32-bit int, 64-bit long, with room for upwards expansion to 128-bit long long when (if?) that becomes relevant. After that, you've got more powers of 256 than you have names in C (well, I suppose you could have a 256-bit intmax_t, and only then do you run out). There is merit to LP64. – Smalt

Maybe this is obvious to you guys, but I think it's worth noting that C# uses different integer sizes from everything else. I recently got tripped up interfacing with a DLL since C# uses 64-bit longs ( msdn.microsoft.com/en-us/library/ms173105.aspx ). – Isaacs

@Compholio: That was not in the least obvious to me, but I've not programmed in C#. Java too has its own set of fixed sizes for integers. – Smalt

@Jonathan Leffler, when you say code has to be revised to exploit 64 bit capacities, are you referring to the limit of 2^32 elements in an array? I'm assuming you can still utilise more than 4gb of heap across multiple allocations for example. Do you know if indices into array type containers in the MS implementations of STL containers 32 bit? – Langrage

In the Windows environment, to get to use 64-bit integers in a program originally written for a 32-bit environment, you have to change the type of some variables (in general). By contrast, in the LP64 environment, any variables of type long are automatically 64-bit when the code migrates. Sizes of arrays, etc, can be an issue, but if you're allocating multiple gigabytes of memory, you usually know about this and have already taken steps to deal with large size objects. – Smalt

A document from X/Open on 64-Bit Programming Models: Why LP64?. See also Data Size Neutrality and 64-bit Support. – Smalt

@JonathanLeffler: For decades, within the microcomputer area, char, short, and long were essentially fixed-sized types with 8, 16, and 32 bits, respectively. The size of int would be 16 on some platforms and 32 on others, but code needing a 16-bit type could use short and code needing a 32-bit type could use long. The wheels only fall off if int becomes 64 bits. – Rasorial

Thanks for explaining the acronyms behind ILP64, LLP64, LP64! – Stationery

In my opinion, one of C's mistakes was not specifying the sizes of the various integral datatypes. As a programmer, declaring a variable with no knowledge of the maximum size value it can hold is a dubious coding practice at best. At the end of the day, all programmers are forced to make some assumptions about the sizes of integral types, and the fact that the C specification is out of step with this reality is an error. – Racial

If you were reinventing C today, even with the benefit of 20:20 hindsight and 45 years of experience with C, it is not clear that you’d make that change. There are many different CPU types and sensible design decisions for an 8-bit or 16-bit CPU would not necessarily be sensible on a 64-bit CPU. I believe there are still a few systems where the word size is not a power of two, for example; there were many more when C was invented. The standard is a treaty between the compiler implementers and the programmers who use the compiler. If you follow the rules carefully, you can write portable code. – Smalt

@deltamind: Easy to say in hindsight, but C originally had to run on machines with 18-bit and 15-bit integers, and 7-bit chars, which, thankfully are no longer fashionable. – Kong

Perhaps worth mentioning that ILP32 ABIs in 64-bit mode are a thing (e.g. AArch64 ILP32 and x86-64 Linux x32), so checking sizeof(size_t) or sizeof(void*) to detect if 64-bit integers are natively/efficiently supported can still have false negatives. I don't know if anyone calls that a LL64 model (where only long long is 64-bit). – Selfpossession

Answer 2

It is not clear if the question is about the Microsoft C++ compiler or the Windows API. However, there is no [c++] tag so I assume it is about the Windows API. Some of the answers have suffered from link rot so I am providing yet another link that can rot.

---

For information about Windows API types like INT, LONG etc. there is a page on MSDN:

Windows Data Types

The information is also available in various Windows header files like WinDef.h. I have listed a few relevant types here:

Type                        | S/U | x86    | x64
----------------------------+-----+--------+-------
BYTE, BOOLEAN               | U   | 8 bit  | 8 bit
----------------------------+-----+--------+-------
SHORT                       | S   | 16 bit | 16 bit
USHORT, WORD                | U   | 16 bit | 16 bit
----------------------------+-----+--------+-------
INT, LONG                   | S   | 32 bit | 32 bit
UINT, ULONG, DWORD          | U   | 32 bit | 32 bit
----------------------------+-----+--------+-------
INT_PTR, LONG_PTR, LPARAM   | S   | 32 bit | 64 bit
UINT_PTR, ULONG_PTR, WPARAM | U   | 32 bit | 64 bit
----------------------------+-----+--------+-------
LONGLONG                    | S   | 64 bit | 64 bit
ULONGLONG, QWORD            | U   | 64 bit | 64 bit

The column "S/U" denotes signed/unsigned.

Tray

FYI, I formatted and expanded this table. – Disepalous

Answer 3

This article on MSDN references a number of type aliases (available on Windows) that are a bit more explicit with respect to their width:

http://msdn.microsoft.com/en-us/library/aa505945.aspx

For instance, although you can use ULONGLONG to reference a 64-bit unsigned integral value, you can also use UINT64. (The same goes for ULONG and UINT32.) Perhaps these will be a bit clearer?

Shutdown

Is there any guarantee that uint32_t and DWORD will be interchangeable? It's not hard to imagine that they might not be [e.g. if the former is a 32-bit int and the latter a 32-bit long, gcc would assume a pointer to one type would be unable to alias the other despite their matching representations]. – Rasorial

Answer 4

Microsoft has also defined UINT_PTR and INT_PTR for integers that are the same size as a pointer.

Here is a list of Microsoft specific types - it's part of their driver reference, but I believe it's valid for general programming as well.

Cicero

Answer 5

The easiest way to get to know it for your compiler/platform:

#include <iostream>

int main() {
  std::cout << sizeof(long)*8 << std::endl;
}

The multiplication by 8 is to get bytes to bits, since sizeof returns a the number of bytes.

When you need a particular size, it is often easiest to use one of the predefined types of a library. If that is undesirable, you can do what often happens with autoconf software and have the configuration system determine the right type for the needed size.

Predikant

Not that it matters, but 8-bit bytes are not actually part of the C spec(clause 3.6 and 5.2.4.2.1 of the C standard). Although you would be hard pressed to find a machine where it wasn't 8 bits, you could check LONG_BIT to see how big your long datatype is. – Trickery

Of course, you're right, it's actually architecture dependent ("addressable unit of data storage large enough to hold any member of the basic character set of the execution environment"), but the most commonly used architectures that equals 8 bits. – Predikant

But the OP didn't ask about his compiler/platform; he asked specifically about 64-bit Windows — presumably because he doesn't have convenient access to a 64-bit Windows system to test on. – Epithet

To be precise you must use sizeof(long)*CHAR_BIT because there isn't always 8 bits in a byte – Melburn

Answer 6

For the history of how the choices were made for UNIX & Windows (the idfferent choices were plausible, Microsoft wasn't being dumb, given its code base.): The Long Road to 64 Bits - Double Double, Toil and Trouble, in https://queue.acm.org/detail.cfm?id=1165766 2006 Queue or https://dl.acm.org/doi/pdf/10.1145/1435417.1435431 2009 CACM

Note: I helped design the 64/32-bit MIPS R4000, made the suggestion that led to <inttypes.h> and wrote the section of C99 explaining motivation for long long.

Irrigation

Answer 7

The size of long on Windows platforms is 32 bits (4 bytes).

You can check this using sizeof(long), which returns the size in bytes.

Carrara

Answer 8

If you need to use integers of certain length, you probably should use some platform independent headers to help you. Boost is a good place to look at.

Supertanker

Fixed-width types are in the language standard – Schooling