Spirit of C

According to the published Rationale document for the C Standard, a major intention of the Standard was to maintain the Spirit of C:

Keep the spirit of C.
The C89 Committee kept as a major goal to preserve the traditional spirit of C. There are many facets of the spirit of C, but the essence is a community sentiment of the underlying principles upon which the C language is based. Some of the facets of the spirit of C can be summarized in phrases like:

• Trust the programmer.
• Don’t prevent the programmer from doing what needs to be done.
• Keep the language small and simple.
• Provide only one way to do an operation.
• Make it fast, even if it is not guaranteed to be portable.

The last proverb needs a little explanation. The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine’s hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that govern the widening of char objects for use in expressions: whether the values of char objects widen to signed or unsigned quantities typically depends on which byte operation is more efficient on the target machine. 

Unfortunately, the authors of the Standard assume that compiler writers will see to uphold the Spirit of C, but the Standard itself doesn't mention it.  This omission has led to decades of needless argument and unreliable code, which could have been avoided if the Standard had made clear a simple principle: quality implementations which claim to be suitable for certain kinds of tasks should be expected to uphold the Spirit of C in a manner appropriate for those kinds of tasks even if the Standard would allow them to do otherwise.

There are many places where parts of the Standard described the behavior of various actions, but other parts classify overlapping categories of actions as invoking Undefined Behavior.  In many such cases, processing the "overlapping" actions in the fashion described by the former parts of the Standard would have a small, but not necessarily trivial, cost, and an ability to perform such actions would be useful for some kinds of tasks but not others.