When if ever was the C language 'int' size altered from the host machine word (register) size into a literal 32 bit size?

Question

From the earliest K&R reference manuals I read, 'int' was synonymous with machine word and it seemed to raise adverse reactions in various user domains. With the UNIX crowd, they minimally required an MMU(Note *1) so the word had to be 32bits at least to do memory management without segmentation overhead such as we saw with 16bit WinTel memory models (tiny, large, huge etc), so the UNIX machines started with 32bits as a minimum for the preferred flat address space.

But that did not define the C int. I also note that the DB crowd have had a preference for immutable storage specifications, so perhaps they too shunned the semantic int for an imperative one.

The reason I ask is that I notice this sudden appearance of an access barrier where manufactured storage disks easily exceed 2TB which but is pegged by the 'long int's stuck on 32 bit 'int's. But the C int specification should not have forced the 32bit word size that now makes the 32bit semantic incapable of implementing 4TB disk access (by mere recompile) to that of 64bit native word machines?

So if there does exist an explicit standard where 'int' is mandated to 32 bits does anyone know its origins (ANSI? IEEE? POSIX? OTHER? etc) and the motivation for that dramatic change from the K&R specification?

If the 32bit standard was made 'pragmatically' then it would surely be equivalent to that other 640K limit which we once lived to regret.

Feedback is pointing towards pragmatism thus far, for instance the Win64 (Answer by @ssokolow): In addition to the reasons give on that web page, another reason is that doing so avoids breaking persistence formats. For example, part of the header data for a bitmap file is defined by the following structure:

typedef struct tagBITMAPINFOHEADER {
        DWORD      biSize;
        LONG       biWidth;
        LONG       biHeight;
        WORD       biPlanes;
        WORD       biBitCount;
        DWORD      biCompression;
        DWORD      biSizeImage;
        LONG       biXPelsPerMeter;
        LONG       biYPelsPerMeter;
        DWORD      biClrUsed;
        DWORD      biClrImportant;
} BITMAPINFOHEADER, FAR *LPBITMAPINFOHEADER, *PBITMAPINFOHEADER;

If a LONG expanded from a 32-bit value to a 64-bit value, it would not be possible for a 64-bit program to use this structure to parse a bitmap file.

And the Amdahl 64 = 32x2 comment given by @ faddenon on the experience of bridging the large double jump from 32 to 64. I give a similar current Redhat/CentOS 8 file access structure that has hidden 32bit ints all over (man statx; from man inode):

   struct statx {
       __u32 stx_mask;        /* Mask of bits indicating
                                 filled fields */
       __u32 stx_blksize;     /* Block size for filesystem I/O */
       __u64 stx_attributes;  /* Extra file attribute indicators */
       __u32 stx_nlink;       /* Number of hard links */
       __u32 stx_uid;         /* User ID of owner */
       __u32 stx_gid;         /* Group ID of owner */
       __u16 stx_mode;        /* File type and mode */
       __u64 stx_ino;         /* Inode number */
       __u64 stx_size;        /* Total size in bytes */
       __u64 stx_blocks;      /* Number of 512B blocks allocated */
       __u64 stx_attributes_mask;
                              /* Mask to show what's supported
                                 in stx_attributes */

       /* The following fields are file timestamps */
       struct statx_timestamp stx_atime;  /* Last access */
       struct statx_timestamp stx_btime;  /* Creation */
       struct statx_timestamp stx_ctime;  /* Last status change */
       struct statx_timestamp stx_mtime;  /* Last modification */

       /* If this file represents a device, then the next two
          fields contain the ID of the device */
       __u32 stx_rdev_major;  /* Major ID */
       __u32 stx_rdev_minor;  /* Minor ID */

       /* The next two fields contain the ID of the device
          containing the filesystem where the file resides */
       __u32 stx_dev_major;   /* Major ID */
       __u32 stx_dev_minor;   /* Minor ID */
   };

No culprits yet, but I suspect IEEE the 'real' pragmatists.

*1) NetBSD which claims portability onto anything requires it to have an MMU

Answer 1

What should be emphasized more because it is perhaps unexpected is that the C standard and POSIX differ in their requirements for the value range of an int. Specifically and importantly, C never mandated 32 bit int sizes. The reason for the discrepancy may be in the different assumptions each standard can make about the hardware.

C is used for a wide variety of programming tasks. Importantly, because it compiles directly to machine code and does not need a huge runtime, it is the language of choice for programming small embedded systems and microcontrollers, often with freestanding implementations: Such systems don't have an operating system, obviously no shell, no processes etc. The requirements the language imposes on C implementations running on such small hardware cannot be too restrictive or they would be broken all the time and hence be useless.

A publicly available ISO C standard draft from 2007, for example, specifies in §5.2.4.2.1

[The] implementation-defined values [from limits.h] shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

The "minimal maximum" for int is then given as

— maximum value for an object of type int
INT_MAX +32767     // 2¹⁵ - 1

By contrast, a POSIX system runs an operating system kernel with *nix-like features (multi-user, multi-tasking among them), provides an elaborate command shell etc. Clearly this requires a much more capable hardware. Which is presumably why the current POSIX standard mandates at a minimum 32 bit integers:

{INT_MAX}
Maximum value for an object of type int.
[CX] [Option Start] Minimum Acceptable Value: 2 147 483 647

The "CX" marks this requirement as an extension to the C standard:

[CX] [Option Start] Extension to the ISO C standard [Option End] The functionality described is an extension to the ISO C standard. Application developers may make use of an extension as it is supported on all POSIX.1-2017-conforming systems. [...]

Where additional semantics apply to a function or header, the material is identified by use of the CX margin legend.

Answer 2

The C standard of the language doesn't mandate a 32-bit int. It defines

sizeof(char) = 1

and

sizeof(long long) ≥ sizeof(long) ≥ sizeof(int) ≥ sizeof(short) ≥ sizeof(char)

It also mandates that the constant in limits.h are at least the values given below

#define CHAR_BIT 8
#define CHAR_MAX UCHAR_MAX or SCHAR_MAX
#define CHAR_MIN 0 or SCHAR_MIN
#define INT_MAX +32767
#define INT_MIN -32767
#define LONG_MAX +2147483647
#define LONG_MIN -2147483647
#define LLONG_MAX +9223372036854775807
#define LLONG_MIN -9223372036854775807
#define MB_LEN_MAX 1
#define SCHAR_MAX +127
#define SCHAR_MIN -127
#define SHRT_MAX +32767
#define SHRT_MIN -32767
#define UCHAR_MAX 255
#define USHRT_MAX65535
#define UINT_MAX 65535
#define ULONG_MAX 4294967295
#define ULLONG_MAX 18446744073709551615

This means that int can be 16 bit or 64 bit, there's no requirement for 32 bit.

As far as I know, POSIX doesn't go beyond that requirement. The only thing that POSIX mandates is that pointer (including function pointer) can be converted to long and back. This is required for shared objects (dynamic libraries).

The standard ISO/IEC 9899:1999 aka C99 can be consulted here http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf There are newer standards (C11) but C99 is imho more relevant.

Answer 3

The C standard only requires that the int type be at least 16 bits wide. There's no requirement that int be 32 bits, though it's a very common implementation choice these days. An exception would be C compilers targeting 8-bit embedded systems which mostly use a 16-bit int.

(Note the C standard specifically requires that int be able to hold a value in the range -32,767 to 32,767 inclusive. There's no requirement that it be able to hold the value -32,768, allowing for sign-magnitude and ones' complement representations.)

The first C compiler was written for Unix running on the PDP-11 and used a 16-bit int. So there wasn't a requirement in the Unix world that int be 32 bits either. Originally POSIX didn't place any additional requirements on int over the C standard, but in 2001 POSIX adopted the Single Unix Specification which requires at least a 32-bit int (though still allowing sign-magnitude and ones' complement representations.) However, unlike Standard C compliance which is commonly claimed by C compilers, very few current operating systems claim to be fully POSIX/SUS-compliant. Most environments that use a 32-bit int are doing so voluntarily.

These days, with the exception of certain embedded systems mentioned above, a 32-bit int is the universal choice of C implementations. In the past there have also been C compilers that used a 36-bit int (for Honeywell GCOS systems) and a 64-bit int (for Cray supercomputers), and of course MS-DOS C compilers used a 16-bit int, but these are all long obsolete.

When 64-bit CPUs became a thing, it might have seemed natural for C compilers targeting these CPUs to use a 64-bit int, but in practice this would've produced slower code because of the increased data size, while adding additional difficulty in porting software to the CPUs.

Answer 4

There is no such requirement in standard C. Traditionally, an int was required to be at least 16 bits, though since the mid-1980s I started to write code as if an int was at least 32 bits, confident I did not intend to support older hardware.

When we moved to 64-bit systems, it was common in some implementations for int to remain at 32 bits, since this eased porting code that had made that assumption.

The first implementation of Unix, and C, was on the PDP-11, a 16-bit machine, so sizeof (int) was 2. The first port of Unix, to an Interdata 7/32. made sizeof (int) be 4.

But the question is confused on other matters.

Unix originally ran on PDP-11 (and without an MMU, either - at least until Thompson and Ritchie got an 11/40), which is a 16-bit machine, and int in C was defined as a 16-bit machine word.

None of this is anything to do with file system size limits. 16-bit CPUs could and did support 32-bit file sizes (or larger, but practical concerns may not have made that sensible). 32-bit CPUs could, did, and do support 64-bit file sizes.

There is a potential problem with API defined in C terms. For example, PDP-11's seek() syscall had to become lseek() when disks could support more than 64K blocks, and an int argument was no longer sufficient.

Windows on 32-bit hardware (the NT family at least) supported 64-bit file sizes, offsets, etc., by the simple expedient of providing two 32-bit arguments to hold a 64-bit value -- either as two actual function arguments, or as a single struct that had two 32-bit members.

Answer 5

If you need a date, then March 12, 1997. That's when Single UNIX Specification version 2 (aka UNIX98) was released. Among other changes to the ISO C standard (via limits.h), INT_MAX and INT_MIN were changed to 2,147,483,647 and -2,147,483,647, respectively (the same as LONG_MAX and LONG_MIN). This of course does not mandate a 32-bit int (64-bit ints are compliant) and it doesn't affect the ISO/ANSI C standards.

Answer 6

When C was invented, there was no particular reason why an implementation would want to use a value for int which was smaller than a register. Although the Standard allowed implementations to choose almost any means they wanted to pick the sizes of integer types, the common practice was that, absent any reason to do otherwise:

• char would be the smallest addressable unit that was at least 8 bits (even platforms with bit-addressable or nybble-addressable storage were required to make all pointers be multiples of char).

• short would be the smallest practical type that was at least 16 bits.

• long would be the smallest practical type that was at least 32 bits.

• long long, when supported, would be the smallest practical type that was at least 64 bits.

• int would be at least large as short, but could be the smallest type of at least 32 bits on platforms that could process such values at about the same speed as smaller ones.

On some platforms like the 68000, 32-bit computations were about 30-50% slower than 16-bit ones, so compilers for that platform often allowed programmers a choice of whether int should be 16 or 32 bits. On platforms where there would be a 2:1 speed difference, int would typically be 16 bits, and on those where there was no speed difference or 32-bit math would be faster, int would typically be 32 bits, but on the 68000 the speed difference fell right in the middle.

Note that it's often considered desirable to have a standard integer type for each each power-of-two size from 8 bits to 64 bits. If int were 64 bits, there would only be two standard types that were smaller than 64 bits, which wouldn't be enough to have a type available for each of the common object sizes (8, 16, 32).

Answer 7

The book "Writing Solid Code" documents an instance where the size of an int changed. There is a section which noted that (once upon a time) Microsoft's own internal C code sources often hard-coded the value '2' (bytes) instead of writing 'sizeof(int)', under the theory that "... well, we OWN the C compiler -surely our own compiler group wouldn't change something as fundamental as the size of an int!". They then proceeded to do exactly that. Broke a lot of code - lots of embarrassment all around ['course that was back in the 80's].

Answer 8

With the UNIX crowd, they minimally required an MMU so the word had to be 32bits at least to do memory management without segmentation overhead

Not true. The PDP-11 had a 16 bit word size and a 16 bit address size which meant that user space processes were limited to 64 kilobytes. I'm not 100% certain but I think that int and char * were both 16 bits for C compilers targeted at the PDP-11. The PDP 11 ran Unix just fine.

But that did not define the C int.

The C int was usually but not always selected to be the optimal size for the target processor. I wouldn't say it was a standard but it was an informal "best practice". For example, the Megamax C compiler that I used with my Atari ST had a 16 bit int because that was the fastest size on a 68000. It did, however, have a 32 bit pointer size because that was the size of the address registers. That used to cause me all sorts of problems with porting code because a surprising amount of it assumed that int and char * were the same size.

On the other hand, the more sophisticated and (crucially for me) more expensive Mark Williams C used 32 bits for both int and char *.

The reason I ask is that I notice this sudden appearance of an access barrier where manufactured storage disks easily exceed 2TB which but is pegged by the 'long int's stuck on 32 bit 'int's. But the C int specification should not have forced the 32bit word size that now makes the 32bit semantic incapable of implementing 4TB disk access (by mere recompile) to that of 64bit native word machines?

Any limits of that nature would be far more complicated than simply "the size of an int". For example, it might be the size of an int times the size of a block or cluster. It really depends on the operating system or the file system, not the compiler. The C definitions of the stat structure are not prescriptive, they are descriptive. i.e. as a rule, the OS defines how big a thing is and the C declaration has to match it, not the other way around.

Answer 9

As a couple of people have noted, Unix originally ran on the PDP-11,¹ which had 16-bit pointers and ints. The original PDP-11/20, which Unix first ran on, had no MMU, but one was added in the PDP-11/45, which was still 16-bit. By V6, Unix implemented a form of virtual memory by copying entire programs in and out of memory as needed.

(Interesting side-note: the shell on V1 had about 350 lines of assembler source code. Large programs, like the C compiler and the assembler, were split into two executables, which communicated using temporary files. PDP-11 Unix programs were probably too small to page! Paging, like 32-bit computing, was introduced by the port of BSD to the VAX.)

Beyond that, Xenix ran on 8086s (with a non-standard MMU, so not 100% IBM-compatible) and 80286s, with a segmented memory architecture and 32-bit pointers but 16-bit ints.

That had interesting consequences when passing a literal 0 to a K&R C function taking a pointer (no prototypes back then!), or to a variadic function like execl. I think things like the NULL symbolic constant come from that background, where an unambiguously pointer-sized 0 was needed.

(According to DMR, the original Unix machine had 24KB of memory installed, which is a bit larger than the original IBM PC's 16KB, but less than half of what a 16-bit address space can handle. This link says V1 processes had 8KB of 'userspace' memory available to them. Of course, by the 1980s Unix programs had expanded to require a bit more memory!)

¹ Technically Unix development started on the PDP-7, but development moved to the PDP-11 before V1, and long before anything we would recognize as 'Unix' today. (The kernel was rewritten in C for V4, in 1973, and for ease of development, not for portability yet.) V6 (1975), which was the first widely-distributed Unix, and V7 (1979), which was the common ancestor of all 'modern' Unixes, including the *BSDs, both ran primarily on the PDP-11. (Although by V6 porting efforts to other machines had started.)

Answer 10

I don't know about a standard, but Microsoft chose the LLP64 model for 64-bit Windows, which means that everything except pointers stays as if the processor word size were 32-bit.

Raymond Chen's blog, The Old New Thing, has an explanation for why they made that choice (which builds on a now-dead link to this MSDN page).

(In short, to make 64-bit porting feasible for pre-uint32_t code which embeds assumptions about type sizes in its definitions of things like file-formats and binary IPC, and to make it easier for 32-bit and 64-bit builds to be made from a common source during the transition period.)

...and, as Patrick Schlüter pointed out and I forgot to mention, the C standard doesn't really say much more than which types are not allowed to be smaller than which other types.