This proposal, specifically it's decision not to use the "concrete semantics", violates several of the stated principles in the C2X charter [0]
Specifically "1. Existing code is important, existing implementations are not" the document relies heavily on what mainstream compilers currently do and making things easier to work with current implementations.
"3. C code can be non-portable" the proposed document seems to preclude the use of C as a "high-level assembler" in that it makes it seemingly undefined to do many simple conversions between a machine word and a pointer.
"4. Avoid “quiet changes.”" This seems to be a quiet change, depending on how one interprets the current ambiguity.
"6. Keep the spirit of C" Specifically (a) Trust the programmer. (b) Don't prevent the programmer from doing what needs to be done. (c) Keep the language small and simple.
"8. Codify existing practice to address evident deficiencies." The document acknowledges that existing code and compiler behavior have diverged.
"11. Maintain conceptual simplicity." This is clearly much more complicated than the "concrete semantics" discussed and previously assumed given the prior ambiguity.
In contrast, I don't see anything in the charter indicating the standards committee should try to retrofit existing implementations' overzealous optimizations onto the language spec. The closest are 6(e) "make it fast", but the explanation there is talking about something different than opportunistic optimizations on a fixed architecture; and "5. A standard is a treaty between implementor and programmer", but that appears to be talking about just the minimum sizes of various integer types.
[0] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm
Specifically "1. Existing code is important, existing implementations are not" the document relies heavily on what mainstream compilers currently do and making things easier to work with current implementations.
"3. C code can be non-portable" the proposed document seems to preclude the use of C as a "high-level assembler" in that it makes it seemingly undefined to do many simple conversions between a machine word and a pointer.
"4. Avoid “quiet changes.”" This seems to be a quiet change, depending on how one interprets the current ambiguity.
"6. Keep the spirit of C" Specifically (a) Trust the programmer. (b) Don't prevent the programmer from doing what needs to be done. (c) Keep the language small and simple.
"8. Codify existing practice to address evident deficiencies." The document acknowledges that existing code and compiler behavior have diverged.
"11. Maintain conceptual simplicity." This is clearly much more complicated than the "concrete semantics" discussed and previously assumed given the prior ambiguity.
In contrast, I don't see anything in the charter indicating the standards committee should try to retrofit existing implementations' overzealous optimizations onto the language spec. The closest are 6(e) "make it fast", but the explanation there is talking about something different than opportunistic optimizations on a fixed architecture; and "5. A standard is a treaty between implementor and programmer", but that appears to be talking about just the minimum sizes of various integer types.
[0] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm