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
int
in C?size_t
variables.