「本物のC」は「Cの精神」と 「freestanding と hosted」と「未定義、未規定、処理系定義」
https://qiita.com/kaizen_nagoya/items/11d66a02479239bf80dd
をより詳細に分解して、Cの原則について振り返る。
Rationale for International Standard— Programming Languages— C
http://www.open-std.org/jtc1/sc22/wg14/www/docs/C99RationaleV5.10.pdf
Existing code is important, existing implementations are not.
A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The C89 Committee did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. On the other hand, no one implementation was held up as the exemplar by which to define C. It was assumed that all existing implementations must change somewhat to conform to the Standard.
C code can be portable.
Although the C language was originally born with the UNIX operating system on the PDP-11, it has since been implemented on a wide variety of computers and operating systems. It has also seen considerable use in cross-compilation of code for embedded systems to be executed in a free-standing environment. The C89 Committee attempted to specify the language and the library to be as widely implementable as possible, while recognizing that a system must meet certain minimum criteria to be considered a viable host or target for the language.
C code can be non-portable.
Although it strove to give programmers the opportunity to write truly portable programs, the C89 Committee did not want to force programmers into writing portably, to preclude the use of C as a “high-level assembler”: the ability to write machine-specific code is one of the strengths of C. It is this principle which largely motivates drawing the distinction between strictly conforming program and conforming program (§4).
Avoid “quiet changes.”
Any change to widespread practice altering the meaning of existing code causes problems. Changes that cause code to be so ill-formed as to require diagnostic messages are at least easy to detect. As much as seemed possible consistent with its other goals, the C89 Committee avoided changes that quietly alter one valid program to another with different semantics, that cause a working program to work differently without notice. In important places where this principle is violated, both the C89 Rationale and this Rationale point out a QUIET CHANGE.
A standard is a treaty between implementor and programmer.
Some numerical limits were added to the Standard to give both implementors and programmers a better understanding of what must be provided by an implementation, of what can be expected and depended upon to exist. These limits were, and still are, presented as minimum maxima (that is, lower limits placed on the values of upper limits specified by an implementation) with the understanding that any implementor is at liberty to provide higher limits than the Standard mandates. Any program that takes advantage of these more tolerant limits is not strictly conforming, however, since other implementations are at liberty to enforce the mandated limits.
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 15 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.
• Make it fast, even if it is not guaranteed to be portable.
Cの精神のうち、再祚の項目は、セキュリティ上の取り組みに置き換えている。
プログラマを信頼するだけでは、膨大なOS、コンパイラの抜け穴を探すことはできない。