I was wondering why C has the long and short integer type in addition to the plain int, and came across the following quote in the C99 Rationale (thanks to this answer here):

[...] In the 1970s, 16-bit C (for the PDP-11) first represented file information with 16-bit integers, which were rapidly obsoleted by disk progress. People switched to a 32-bit file system, first using int[2] constructs which were not only awkward, but also not efficiently portable to 32-bit hardware.

To solve the problem, the long type was added to the language, even though this required C on the PDP-11 to generate multiple operations to simulate 32-bit arithmetic. Even as 32-bit minicomputers became available alongside 16-bit systems, people still used int for efficiency, reserving long for cases where larger integers were truly needed, since long was noticeably less efficient on 16-bit systems. Both short and long were added to C, making short available for 16 bits, long for 32 bits, and int as convenient for performance. There was no desire to lock the numbers 16 or 32 into the language, as there existed C compilers for at least 24- and 36-bit CPUs, but rather to provide names that could be used for 32 bits as needed.

This seems to answer my question, but I am a little unclear as to what it is saying and would like to check my understanding:

  • long was added for portability between the 16-bit PDP-11 and the new 32-bit machine. A C programmer wanting to target both would have used long. Is this correct?
  • Before the arrival of the 32-bit machine, C was only used on the PDP-11. During this time, there was only one integer type, namely int (did unsigned int exist?), which had a de facto size of exactly 16-bits. After the arrival of the 32-bit machine, long and short were added to the language. long was specified as being at least 32 bits in size, short as being at least 16 bits in size, and int as being whatever size as "convenient for performance". Is this correct, or were int and long initially defined as having fixed widths?
  • Does "convenient for performance" mean that an implementation was free to choose whichever size was most performant for its hardware? Did the chosen size have to obey the relation short ≤ int ≤ long?
  • When and why was short added to the language? (Also, §2 Overview of this memo for the VAX-11 says "a short still occupies 2 bytes," which makes it sound like short was already around by then, but the second paragraph ofthe quote above says, "Both short and long were added to C").
  • 8
    Why? CPUs often support more than one length of integer, even if multiple instructions are needed for longer lengths. Programs can usefully use more than one length of integer, Given that, it doesn't seem surprising that C supports the idea. The specific words used (short, long) were likely copied from Algol 68.
    – dave
    Commented Jun 17 at 2:41
  • 2
    The VAX was not the first 32-bit machine to run Unix; that was the Interdata 7/32.
    – dave
    Commented Jun 17 at 2:59
  • 2
    Note your quoted text doesn't say much about portability. It says "long was introduced to be able to express file sizes and file pointer positions larger than 16 bits", which is an entirely different need (and repeated again later for long longwhen file sizes started to exceed the 32-bit limit).
    – tofro
    Commented Jun 17 at 7:28
  • 3
    @GiacomoCatenazzi - I dispute 'long before C'. C began (out of B) around 1971. The Intel 8008 was released in 1972. And what 7-bit CPUs were there? Lastly, 'int' was optional from the beginning. Maybe you're writing from a home-computer point of view?
    – dave
    Commented Jun 17 at 12:00
  • 2
    @scm: The normal way to target 16-bit and 32-bit systems was to use "short" for 16-bit quantities, "long" for 32-bit quantities, and "int" for quantities where 16 bits would be enough on systems that couldn't accommodate allocations over 64K, but 32 bits might be needed on systems that could handle larger objects.
    – supercat
    Commented Jun 18 at 20:43

6 Answers 6


long wasn’t added for portability to a new 32-bit machine; it was added to make it easier to write code manipulating 32-bit quantities. According to the C99 rationale, the driver for this was a new 32-bit file system, not a new 32-bit machine: a 16-bit signed int can only represent offsets up to 32767, which isn’t a lot.

I don’t know for sure exactly when long was added to the language; The Development of the C Language says

During 1973-1980, the language grew a bit: the type structure gained unsigned, long, union, and enumeration types, and structures became nearly first-class objects (lacking only a notation for literals).

short, long, and unsigned integers were formalised by the time the C machine model was described, for example in Johnson and Ritchie’s Portability of C Programs and the UNIX System paper. They are mentioned in the first draft of The C Programming Language, where they are defined as

int: an integer, typically reflecting the natural size of integers on the host machine. […] short and long refer to different sizes of integers; unsigned implies that the number is to be treated as a logical quantity, not an arithmetic one.

This doesn’t mention specific sizes; there follows a table listing varying sizes for different machines, the PDP-11, Honeywell 6000, IBM 370, and Interdata 8/32. The Honeywell and IBM systems are mentioned in the earlier paper; the C compiler was “retargeted” there much earlier than more comprehensive portability efforts, around 1973, so int’s varying size requirements were well-known, and the major limitation noted in the first portability memo isn’t type sizes, it’s the assumption that pointers are the same size as ints.

The only size “constraint” in the early draft is described as

About all you should count on is that short is no longer than long.

The later machine model is more detailed:

Variables declared short are at least 16 bits in length; those declared long are at least 32 bits. Most are declared int, and must be at least as precise as short integers, but may be long if accessing them as such is more efficient.

I’m not sure exactly when short was added to the language; in the Unix history repository it only appears in V7, but that’s Unix-focused, not C-focused. long was present in V6.

  • If file offsets were the only issue, having separate absolute and relative versions of "fseek", where the former uses an opaque structure returned by a variation of "ftell" and the latter accepts a pair of integers and multiplies them together, could have accommodated large files pretty well without having to add new integer types to the language. There are many tasks, though, for which double-word support is useful. The note about unsigned as "logical values" is interesting; it's too bad the language never included a family of unsigned types that were intended to be used as numbers.
    – supercat
    Commented Jun 17 at 19:42
  • 1
    @supercat That's exactly what they did in the early days. But it proofed to be complicated, clumsy and error-prone. So, not a sustainable solution.
    – tofro
    Commented Jun 19 at 7:04
  • and that's the thing about C: it's supposed to be portable. So, if you need to implement your own "addition of two numbers" for every machine you want to do anything > 16 bit on, including dealing with machine specifics of integer math, you end up with non-portable code for very basic operations. Not to mention that long a, b, c; c=a*b reads much nicer than char a[4]; char b[4]; char c[4]; pdp11_mult_32x32(&a, &b, &c); would have read (not even sure that compilers would have supported such long function names, though. So, maybe would've been p11_m32i(&a, &b, &c); in all its clarity); Commented Jun 22 at 16:50
  • so, C defines a machine that can add long numbers, and the math has to be correct, and it's the compiler's problem to make that happen. Much nicer for the user. Commented Jun 22 at 16:52

The predecessor of C, called B, was originally implemented along with UNIX on an 18-bit minicomputer, the PDP-7.ⁱ Computers of the 1970s came in a wide variety of word sizes, including 8-bit (MOS 6502, Intel 8080), 12-bit (DEC PDP-8), 16-bit, 18-bit (DEC PDP-4), 24-bit (IBM System/360), 32-bit and 36-bit (IBM 7090, DEC PDP-10). One early project in this language was a cross-compiler from B to the GE-635.

Dennis Ritchie created C when Bell Labs began using PDP-11s, so there were a few years when the PDP-11 was the only machine with a C compiler. One of the biggest motivating factors was adding types to the language. B has only one type: a register-sized word. Pointers were just words, too, and you could do arithmetic on them, which worked because the machine was word-addressed. The PDP-11, however, could address 8-bit bytes. Ritchie wanted C to be able to represent all the types the PDP-11 could handle: the 8-bit bytes that the machine could address, the 16-bit words and pointers that fit into a register, and both 32-bit and 64-bit floating-point numbers.² He also wanted pointer and array arithmetic to work on arrays of different types. Originally, int was the machine’s native word size, assumed to be 16 bits.

This began to change in the late ’70s, for several reasons: the extended instruction set of the PDP-11 began supporting 32-bit math (although this originally was supported through functions such as div), Steve Johnson began to write the Portable C Compiler, and Ritchie and Thompson started porting C to the Interdata 8/32.³ However, as your source said, the immediate impetus to add long had nothing to do with the CPU at all. A 16-bit int could only support files 32,767 bytes or less long, and that was not enough for a modern operating system. The long type was originally created to hold a 32-bit file offset, manipulate files using lseek, and index large arrays.

Since some of of the machines C was now being ported to were 32-bit, including the Interdata 8/32, the developers decided that int would become 32-bit on 32-bit machines, so all existing code would become 32-bit automatically when recompiled. (Ports to systems with registers smaller than 16 bits made char the native byte size and int two bytes, but C was not originally designed for them.) This meant that they now needed a type that was 16 bits wide everywhere (or as little over that as possible), to represent things like a port number in a TCP header and to save space. This became short.

There was one anti-pattern that C kept running into face-first, over and over, despite past experience. The C and UNIX APIs were designed in a very short-sighted way that built assumptions about the architecture into the type system: long was both exactly 32 bits wide (and used for things like IP addresses, filesystems and packets), but also the type of things like file sizes or the number of seconds since January 1, 1970 that needed to become larger than 32 bits and large enough to hold the bits of a pointer. C was also originally designed in a culture where the user always had the source code and porting always meant recompiling for a new computer, but at the turn of the century, operating systems and compilers needed backward compatibility with both legacy APIs and ABIs. This forced 32-bit, and later, 64-bit, implementations to choose which of these assumptions that legacy code depended on to break. Then the official standards needed to leave room for all of these choices. One C compiler in the ’90s even extended int to its new native word size of 64 bits, but kept long 32 bits wide for backward compatibility.

At that time, the C Standard Committee was reluctant to add new keywords that might break existing programs, so they reused long to create a type long long int. They also added, in header files, a large number of types with a very specific meaning, which included: off_t for a file offset, time_t for a time in seconds, uint_least32_t for the smallest unsigned type at least 32 bits wide, int_fast16_t for the fastest type at least 16 bits wide, uintptr_t for an unsigned type wide enough to store a pointer, uint8_t for a type that is exactly 8 bits wide and guaranteed to truncate to 8 bits if it overflows, and so on. At least two of these created problems of their own just this year: C23 is deprecating intmax_tand uintmax_t, because no native integral type was allowed to be wider than these, but many systems that had originally defined them as 64-bit were now unable to get rid of that piece of technical bit from their ABIs. This had been holding compilers that already supported 128-bit integers back from making int128_t and uint128_t official.

Where that leaves us today is that you can’t really assume that any native type is a particular size. The actual requirements have forced char to be 32 bits wide on some systems, and even led to a 64-bit short int on the Cray T90. However, C23 is dropping the idea that C still needs first-class support for every architecture of the past sixty years, and will require every conforming implementation to have types that are exactly 8, 16, 32 and 64 bits wide. If you need the fastest type that’s at least 16 bits wide, that’s int_fast16_t, and most types whose size could vary from system to system are now defined with a distinct name in modern APIs.

ⁱ A legacy of this in modern C is that both int and short have always officially been at least 16 bits wide, so as not to break compatibility with any 18-bit hardware out there. Another is that the octal numeric constants used on systems whose word size was divisible by 3 kept being used in C for things like file permissions and character escapes. Dennis Ritchie also believes the auto-increment memory cells of the PDP-7 are what suggested the ++ and -- operators to Ken Thompson.

² The quirks of the PDP have affected C in numerous ways, such as the implicit promotions of float to double, and types narrower than int to int. (The latter is especially a fun source of gotchas for language-lawyers, as a great many types are allowed to be narrower than or exactly the same size as int, on the DeathStation 9000.) In fact, early C had only implicit casts.

³ None of these ports ever had as much influence as the 16-bit implementations that people actually used. However, the C standard has a lot of clauses in it that were intended to support obscure hardware from the late ’70s, and the committee historically declared most of them “undefined behavior.” For example, a char* is allowed to be bigger than an int* (but not vice versa), because some mainframes used to have separate word- and byte-pointer types, and signed arithmetic overflow is undefined behavior because some old CPUs would trap on overflow. Fifty years later, when nobody’s written a new C compiler for any of those machines in decades, the main effect of this is to give compilers permission to make unsafe optimizations if any code branch could conceivably lead to some kind of undefined behavior.


Addressing the question's four bullet points specifically:

  • long was added for portability between the 16-bit PDP-11 and the new 32-bit machine. A C programmer wanting to target both would have used long. Is this correct?

No. long was added because growing interest in 32-bit filesystems, including for the PDP-11, highlighted a need to work with 32-bit integers, and this was messy and inconvenient with only the 16-bit ints that were natural for the PDP-11.

In any case, then and now, a programmer wanting to work with the machine's native word size would use int. This was and is beneficial for performance. After the introduction of long, a programmer would use that when they wanted a type that was somehow "long", even if that happened to be costly. In practice, one could rely on it to provide at least 32 bits. Particularly so on Unix.

  • Before the arrival of the 32-bit machine, C was only used on the PDP-11.

No. C was not used anywhere prior to the arrival of 32-bit machines, which preceded both the PDP-11 (introduced 1970) and C (initial development 1970 - 1973, from predecessors BCPL and B). At least one 32-bit machine, the Manchester Baby, preceded them by more than two decades, having been commissioned in 1948. Although the Manchester Baby was primarily a proof of concept, there were commercially available 32-bit machines in the 1960s, such as the IBM System 360 / 30, introduced in 1964.

C was implemented on multiple platforms from early on, including the Honeywell 635 and IBM 360/370 (36-bit and 32-bit machines, respectively), both by 1973. Before these, yes, C was available (within Bell Labs) for a time only for the PDP-11, but that's not related to the introduction of long.

During this time, there was only one integer type, namely int (did unsigned int exist?), which had a de facto size of exactly 16-bits.

There was time very early in C's development when there were only six data types: int, char, and pointers to and arrays of those. char is classified as an integer type, and back then, the distinction between integers and pointers as different type categories was not really a thing.

So depending on how you want to count, that could be one, two, or four integer types. But if you mean that there was a time when no short or long existed in C, then yes, that's true. But not before there were 32-bit machines, nor before there were 32-bit filesystems. I'm having trouble tightening the timeline enough to be sure, but Dennis Ritchie's history of C seems to indicate that the first Honeywell and IBM ports of C were in this period.

Yes, when C was only on the PDP-11, the width of int was 16 bits and only 16 bits, but this is not remarkable, as it was natural for that machine.

After the arrival of the 32-bit machine, long and short were added to the language. long was specified as being at least 32 bits in size, short as being at least 16 bits in size, and int as being whatever size as "convenient for performance". Is this correct, or were int and long initially defined as having fixed widths?

Long after the arrival of 32-bit machines, and at least somewhat after the arrival of 32-bit filesystems, long was added to the language. This was somewhere in the 1973-1977 time frame. short was added in the same time frame because it (too) is described in the first edition of K&R, published in 1978.

The motivation for long notwithstanding, K&R does not specify a minimum width for it, nor for short. It recommends that short should be shorter than long where practical, but documents an implementation for the Honeywell 6000 in which short, int, and long were all 36 bits. K&R does say that "int will normally reflect the most 'natural' size for a given machine."

There does not seem to have been any time in C's history when exact sizes for int, long, or short were specified as part of the language.

  • Does "convenient for performance" mean that an implementation was free to choose whichever size was most performant for its hardware?

Yes, and that's exactly what they did.

Did the chosen size have to obey the relation short ≤ int ≤ long?

According to K&R, "about all you should count on is that short is not longer than long". But that's more about specific sizes, and I suppose they may have been taking it for granted that int would be neither shorter than short nor longer than long.

  • When and why was short added to the language?

As already discussed, short was added somewhere in the 1973 - 1977 period. I can't nail it down more precisely than that, but I speculate that after long was conceived, it seemed natural to introduce short as a counterpart. I imagine that it also may have had a similar practical impetus: on a machine where the natural size for an integer is 32 bits (say), one might want to handle data structures containing integer fields narrower than that. short provides a similar kind of convenience for that as long provides for 32-bit fields on a 16-bit machine.

(Also, §2 Overview of this memo for the VAX-11 says "a short still occupies 2 bytes," which makes it sound like short was already around by then,

Yes, short and long were both added before 1978, when that memo was written. "Still occupies 2 bytes" is part of a comparison between the PDP-11 implementation of C and the new VAX-11 implementation, which was prepared as part of porting UNIX to the VAX described in the memo. That was performed in about five months, from December 1977 through may 1978. short occupied 2 bytes on the PDP-11, and still did on the VAX-11. On the other hand, int, long, and pointer types were all 32 bit on the VAX-11, which was a change from the PDP-11 for pointers(!) and int.

but the second paragraph ofthe quote above [from the C99 Rationale] says, "Both short and long were added to C").

Yes. They were added in about the same time frame, which preceded the VAX-11 memo. I don't see any inconsistency between that and the rationale document.

  • 1
    I would think short would have been a natural addition before long, since its usefulness would have been apparent on the first machine which used a 4-byte int and could load or store two-byte quantities reasonably efficiently, and since adding it wouldn't change anything fundamental about the language. Implementations which wouldn't benefit from short could treat it as synonymous with int.
    – supercat
    Commented Jun 17 at 22:19
  • Perhaps so, @supercat. I can only speculate. However, my attempt to put myself in the heads of the principals involved leads me to imagine there being a barrier to overcome in the form of accepting that more arithmetic integer types than just int were desirable at all, no matter how natural they might be for any given target. long addressed a significant pain point for the PDP-11, much more so than short did for 32-bit machines. Plus, the available historical and retrospective accounts talk much more about long than about short, which makes me think it was long that came first. Commented Jun 18 at 13:18
  • Adding long would represent a far more substantial change to the language than would adding short. Adding short only requires adding 'load short' and 'store short' operations which are analogous to the corresponding operations with char, and there's not much to debate about in terms of semantics, thus it would be something that an implementation could "just do" without any particular fanfare, so there may not "need" to be much written about it.
    – supercat
    Commented Jun 18 at 14:38
  • Agreed, @supercat. But I don't take the the Bell Labs crew to have been looking for features to add just for the sake of it, no matter how natural they may have been. At least, not early on. And B had only one type, so they had no expectations for a rich type system. char-based access was the new thing that motivated C, and with int and char, access to storage between the sizes of those two, though not as easily expressible as it could be, would not have been too bad. What distinguished and motivated long was the need for 32-bit arithmetic. Commented Jun 18 at 14:58
  • Even before machines had octet- or nonet-addressable storage, it was common for languages to support packed data types; I think B could pack string literals that way, and Pascal had explicit Packed Array of Byte. If a program for a machine with 32-bit registers needs to store a lot of numbers which are too big for char, but could be packed two per word, adding support for a short type (and implicitly, arrays of short) to a compiler could be easier than requiring that the application wrap all accesses to the collection with function calls.
    – supercat
    Commented Jun 18 at 15:21

In the early days of high-level languages (e.g. definitely for early versions of FORTRAN, and I think many versions after that), integer types were used for small numbers such as counters, and floating-point values were used for everything else. This trend continued for many languages well into the 1980s (e.g. Turbo Pascal had a 16-bit Integer type and a 48-bit Real type). Because C was designed for a machine with storage that could be addressed in units smaller than its basic register size, it had a type (char) that corresponded with the addressable unit size which was separate from its register-sized int. The only things that could be done with a char would be loading it (yielding an int) and storing it (writing the bottom portion of an int while discarding the rest).

When machines emerged where an int would be four bytes, it would have become apparent that it would be useful to treat half-word values as a type in their own right, but short adhered to the same basic principle as char, supporting only load and store operations.

After while, it became apparent that even on machines which could only efficiently operate on values up to 32767, there was often a need to work with larger values more efficiently than would be possible using floating-point types. The addition of long to C broke the principle that all integer computations would be done using type int, but the advantages were worth the hassles it posed in the era before function prototypes were invented.

It may be worthwhile to note that on many architectures, operations on long values would take at least twice as long as operations on int values, but in many cases it would be easier for a compiler to translate long operations into machine code that would "only" take about twice as long, than to translate any C code that used multiple char or int values into efficient machine code. In C, if all one had was int, code to add two double-length numbers on a quiet-wraparound two's-complement platform whose relational operators might be wonky (as described in the 1974 C reference manual) would need to be something like:

/* Note that a low-order word of -32768 to -1 represent a value from
   +32768 to +65535 */
new_low = low1 + low2;
new_high = high1 + high2;
if (((~new_low & (low1 | low2)) | (low1 & low2)) & 0x8000)

If a target platform can generate a carry flag or robustly perform unsigned comparisons, the condition being tested in machine code could be vastly simplified, and if it has an "add with carry" it could be simplified further still, but it would be very hard for a compiler given code like the above to benefit from such abilities.

  • 2
    C was intended to replace most assembly language programming. It was common to use double word integers in assembly language.
    – John Doty
    Commented Jun 17 at 15:10
  • 1
    The tail-end comment about "before function prototypes were invented" is important because it reminds you that there are other semantic rules that existed in C that either had to be maintained or explicitly changed to make 32-bit arithmetic "first class" in the language. (Many of those rules exist to this day ...)
    – davidbak
    Commented Jun 17 at 15:16
  • 2
    @davidbak: I wish the Standard had "officially" allowed implementations to treat old-style functions and argument-less functions as being in one universe and functions that took new-style arguments as being in another (e.g. adding a different prefix to the linker symbols). On e.g. the 68000, a convention of passing the first three non-pointer arguments in D1-D3, and the first three pointer arguments in A0-A2, could greatly improve efficiency, but a stack-based convention with 32-bit "int" would allow a literal zero argument to behave as either null or integer zero, interchangeably.
    – supercat
    Commented Jun 17 at 15:26
  • 3
    @davidbak: Having old-style functions use a stack-based convention, while prototyped functions used a register-based convention, could allow "best of both worlds" behavior, compared with requiring that compilers allow new-style functions in one module must be callable from a module without prototypes. I used an 8051 compiler which embodied that approach, and thought it much better than requiring that prototyped and non-prototyped functions be interchangeable.
    – supercat
    Commented Jun 17 at 15:29
  • 1
    @supercat - Yes. And remember that the Microsoft C (then C++) compilers introduced "keywords" (reserved words?) that let the programmer explicitly specify different calling conventions on a per-function basis so the programmer could control interop vs. efficiency.
    – davidbak
    Commented Jun 17 at 16:08

I believe that C adopted the idea from Algol68, which offered types such as "int", "long int", "long long int" etc. I don't recall whether Algol68 actually defined the sizes of these types. Pascal (which was developed in many ways as a deliberate rival to Algol68) used explicit ranges, e.g. 1..1000, which provided a solution that was independent of hardware architecture, but was potentially inefficient because assignments had to be checked.

The C language didn't specify the actual sizes of short, int, long etc, but many supposedly portable C applications assumed the PDP implementation, which made porting difficult if your target machine architecture was different. On ICL VME mainframes, for example, the machine instruction set only supported 32, 64, and 128 bit integers, and 16-bit arithmetic had to be simulated by software. The first iteration of the C compiler, IIRC, used short=32, int=64, long=128 because that was conformant and mapped to the hardware, but it proved totally impractical for porting existing code.

  • Programs which are designed to perform octet-related tasks on systems which support octet-addressable storage will have to be reworked to operate efficiently on systems that don't, regardless of the language in which they are written.
    – supercat
    Commented Jun 20 at 14:38

As computer technology has advanced, the "width" of processors has grown. In the early days of computers, the computer could only move data around in 8 bit chunks. Later this was increased to 16, then to 32.

Early versions of C supported just 16 bit integers. When 32 bit computers came along, they couldn't take advantage of the larger processor width. So "long" was added.

Then the designers of C made what is, in my humble opinion, a mistake. Instead of saying that an int is such-and-such a size, period end of story, they said that a short is 16 bits, a long is 32, and an int is the "natural" size for the given processor. This made writing compilers easier. If you were writing a compiler for a 16 bit machine, you could make an int 16 and everything worked cleanly and nicely. If you were writing a compiler for a 32 bit machine, you could support 32 bits and take advantage of the larger size.

But this created a serious compatibility problem. A program that worked fine on a 32 bit computer might compile with no errors on a 16 bit computer ... but not work. If at any point the program used 17 bits, it would work on the 32 bit computer but fail on the 16 bit computer. Even though it was the exact same code that ran successfully on another computer.

Even if you had to make other changes to make the program work on the new computer -- changes to accommodate different file systems or whatever -- a programmer might well not realize that he needs to change some of the int's to long's. The worst case would be if it USUALLY works, so that he can run tests and everything appears good. Then one day he gets a value bigger than 16 bits and kablam.

The goal was not to improve compatability between 16 and 32 bit computers. Indeed that issue was pretty much ignored. The goal was to allow programmers to take advantage of 32 bit computers when they were available.

  • 6
    How do you square all this with the 1973 Honeywell 6000 C compiler, where short, int, and long are all 36 bits in size? Commented Jun 17 at 13:29
  • 5
    @Barmar I know where C development started; but C had outgrown the PDP-11 before it was first released outside Bell Labs, and its design was arguably not finished by then. Even ignoring that, the claims in this answer about type sizes just don’t align with the reality of early C compilers. Commented Jun 17 at 14:25
  • 3
    @Barmar exactly. But I would rather have Jay answer these questions ;-). Commented Jun 17 at 14:51
  • 3
    @Jay: The unsigned char type is specified as capable of holding values up to at least 255, and as not having any padding bits; unsigned short and unsigned int are both specified as being capable of holding values up to at least 65535.
    – supercat
    Commented Jun 17 at 16:55
  • 4
    In the early days of computers, the computer could only move data around in 8 bit chunks. This is not true. You have a microprocessor view of the world. Very early electronic computers moved data around a bit at a time ('serial' CPUs) but nevertheless managed to support, for example, 17 or 35 bit words. A little later, 36-bit parallel machines were commonplace, e.g. IBM 709 in 1957. 8-bit systems were much later. '8 bits' wasn't even an interesting sub-part of a word until System/360.
    – dave
    Commented Jun 17 at 20:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .