Interesting to think that the assumptions of C as a language evolved mostly against the VAX architecture. It seems that if the VAX doesn't make a distinction, then C doesn't (tend to) have any concept of that distinction either. Examples:

- Pointer types are basically fungible in C (otherwise there would be no void-ptr type)

- There's no compile-time knowledge of the segment a pointer references to prevent you from dereferencing a pointer to an offset from segment A when segment B is loaded (compare this to Rust's parameterization of Box types by their allocator)

- Struct padding is painful and tacked on

- "unsigned char" isn't default even though it'd make much more sense for it to be (What "char"acter is negative? You can have a signed byte/octet, but a character is—in 1979, at least—basically an enum/sum type.

Actually C disallows converting function pointers to/from void pointers.

Can you get away with that in pre-ANSI C? I wouldn't be surprised.

for pre-ANSI C most of these questions are answered by "it depends on the compiler" which is why ANSI C happened. Of course the answer is still "it depends on the compiler" for this behavior, since it's not defined what it does in ANSI C, just that it's not portable to do it.

I remember working on a Fujitsu box in 1993, which used some sort of weird System V Unix with pre-ANSI C and weirdly abbreviated man pages in Engrish. (shudder) Yeah.

Against the PDP-11, which the VAX directly descended from, but yes. Unix and C were written for the PDP series.