There have been spirited discussions in the past on when/why/how C compilers do/should automatically widen operations from 8-bit to 16-bit. In tight microcontroller apps with lots of references to 8-bit variables the widening can cause much larger code. This thread has much of the pros-and-cons:
So we find clawson saying:
So compilers that generate 8 bit access code without being forced to do so are not adhering to C standards!
C likes to promote pretty much everything and anything to an int.
I was looking up something in my dusty 1989 "ANSI C: A Lexical Guide"/Mark Williams and came across the "as if rule":
The Standard does not command implemetors to implement all of its models and standards. Rather, implementors should write their implementations to bring about the same result, as if the model had been implemented directly.
For example, consider the following expression:
char c1, c2, c3;
c2 = c1 + c3;
The Standard states that such an expression must be performed as if c1 and c3 had been promoted to ints before performing the arithmetic. An implementor, however, may choose not to promote the operands to ints if the same result is obtained. It is as if the operands were promoted and integer arithmetic performed, when in fact, the program was optimized by performing character arithmetic.
Now, the referenced thread dealt with widening constants, not variables. I'd assume the same rationale would apply. Also, this was the first "ANSI C" and there have been several standard C releases since then. And this is one author's interpretation.
But according to this, compilers CAN e.g. do 8-bit switch() if they want, or not widen a constant as in the referenced thread, etc. Not widening is not non-conforming according to the as-if rule.