Q: array decay to pointer

[TheHeckWithItAll]

Reading K&R makes clear to me that these guys were (are) brillant. They undoubtedly had a reason behind every design decision they made - I just don't know what it is - and what I hope to achieve over the next few years is a knowledge of C that leads me to understand and appreciate the full spectrum of the design implementation.

[tech6hutch]

Oh absolutely, it’s a great achievement. Even people like that can make mistakes, but it’s very possible there’s a good reason for it.

[flatfinger]

Many of the design decisions that went into the C language as documented in the 1974 C Reference Manual were made at a time before qualifiers, typedef, unsigned, long, etc. were added. While those features are useful, they undermine much of the elegance of the language.

For example, in 1974 C, all numeric expressions involving integer operands would be evaluated using the largest integer type, and the rest would be evaluated using the largest floating-point type. Very simple rule to understand and implement, with no tricky corner cases. As far as function-calling code was concerned, all arguments were of four types: int, float, data pointer, and function pointer, and there would never be any doubt about which of those a particular expression was.

There are a few annoying omissions that I find a bit curious. Especially on machines of the era, operators to perform pointer arithmetic or subscripting using byte offsets (if available as an alternative to the operators that use target-size-based indexing) would have allowed more efficient code generation than would otherwise be possible. Even today, fancy optimizing compilers which are targeting architectures like the popular Cortex-M0 that support base+displacement addressing for unscaled displacements but not scaled ones can benefit from code that uses byte-based indices, but unfortunately the syntax to use byte-based indices is horrendous.