------- Comment #6 from malitzke at metronets dot com 2007-06-27 20:43 -------
This appears to be the essence of what I wanted note per 3) in comment 3
In going from pdf to html via pdftohtml I was forced to do some realigning and
erase special symbols by hand. If you do not trust go to the actual document.
If this is what bound the standardization committee it is certainly binding on
myself the GCC apparently feels differently. The Xfree86-xorg inspires me to
believe that reason will prevail one way or another.
The original X3J11 charter clearly mandated codifying common existing practice,
and the C89 Committee held fast to precedent wherever that was clear and
unambiguous. The vast majority of the language defined by C89 was precisely the
same as defined in Appendix A of the first edition of The C Programming
Language by Brian Kernighan and Dennis Ritchie, and as was implemented in
almost all C translators of the time. (That document is hereinafter referred to
asK&R.)
K&R was not the only source of existing practice. Much work had been done over
the years to improve the C language by addressing its weaknesses, and the C89
Committee formalized enhancements of proven value which had become part of the
various dialects of C. This practice has continued in the present Committee.
Existing practice, however, has not always been consistent. Various dialects of
C have approached problems in different and sometimes diametrically opposed
ways. This divergence has happened for several reasons. First, K&R, which once
served as the language specification for almost all C translators, is imprecise
in some areas (thereby allowing divergent interpretations), and it does not
address some issues (such as a complete specification of a library) important
for code portability. Second, as the language has matured over the years,
various extensions have been added in different dialects to address limitations
and weaknesses of the language; but these extensions have not been consistent
across dialects.
One of the C89 Committee's goals was to consider such areas of divergence and
to establish a set of clear, unambiguous rules consistent with the rest of the
language. This effort included the consideration of extensions made in various
C dialects, the specification of a complete set of required library functions,
and the development of a complete, correct syntax for C.
Much of the Committee's work has always been in large part a balancing act. The
C89 Committee tried to improve portability while retaining the definition of
certain features of C as machine-dependent, it attempted to incorporate
valuable new ideas without disrupting the basic structure and fabric of the
language, and it tried to develop a clear and consistent language without
invalidating existing programs. All of the goals were important and each
decision was weighed in the light of sometimes contradictory requirements in an
attempt to reach a workable compromise.
In specifying a standard language, the C89 Committee used several principles
which continue to guide our deliberations today. The most important of these
are:
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 .
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__ (contract) 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 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.
--
malitzke at metronets dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dnovillo at google dot com,
| |law at redhat dot com,
| |kenner at nyu dot edu, ian
| |at airs dot com, mark at
| |codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32493
