[COFF] [TUHS] Re: Hypothetical: Could MULTICS have been written in C, if available?
Dan Cross via COFF
coff at tuhs.org
Thu May 28 00:16:29 AEST 2026
On Wed, May 27, 2026 at 6:49 AM Noel Chiappa via COFF <coff at tuhs.org> wrote:
> [snip]
> In that later era, OK. They would not have worked in mine; on a PDP-11, an
> 'int' was 16 bits. (I wonder how long an 'int' is on modern 64-bit
> architectures? They probably had to keep it at 32 bits, or it would have
> broken too much code - or was it defined to always be 32 bits in later C
> specs?)
On most (??) 64-bit machines, `int` is 32-bits.
During the 32->64 bit transition, there was a lot of variation and
debate around the "ILP" widths: that is, what the widths of `int`,
`long`, and pointers should be. I think most Unix-y systems settled
on I32LP64 (usually just written, "LP64"), where `int` is 32-bits and
long and pointers are both 64-bits; some systems were ILP64 (`int`,
`long`, and pointers are all 64-bits), and several are "LLP64" where
`int` and `long` are 32-bits, but `long long` and pointers are
64-bits. There are several other variations on the theme; old Crays
also made `short` 64-bits.
I asked a person working on clang and LLVM about 32-bit `int` on
64-bit machines once; why not make `int` 64-bits? The response was
that that was "too big" for most things and there was no significant
advantage otherwise. It might have also been marginally slower for
stores on some machines around that time.
On the other hand, the exact-width integer types, as defined in
`<stdint.h>`, are exactly what they say: integers of an exact width,
with names like `int32_t`, `uint64_t`, and so on. A sort of annoying
issue with them is that their introduction was not accompanied by
`printf`-family formatting directives; instead, implementations are
expected to provide `<inttypes.h>`, which defines macros that expand
to short strings holding the format specifiers for each type; one is
expected to use string concatenation behavior to use them. E.g.,
uint64_t foo = 0xdeadbeefcafeULL; /* Is ULL correct here? Probably. */
printf("foo is %#"PRIx64" in hex\n", foo);
When run, this prints, "foo is 0xdeadbeefcafe in hex". But man, the
code looks like someone whacked it with an ugly stick.
- Dan C.
More information about the COFF
mailing list