[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel

["malitzke at metronets dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #14 from malitzke at metronets dot com  2007-06-29 21:14 -------
The first two sentences of your comment was never disputed by either myself nor
from how I read Mr Torvald's comment. 

The only thing under dispute is the completely unwarrented trnasformation of a
subtraction into a division. 

I am not speaking for the kernel people here but for myself; their subtraction
just started me off. There are vey good reasons to avoid ligcc, like atomicity,
reentrancy or plain orneryness.  If I clearly specify a subtraction any C
compiler worthy of its name has no right transform that subtraction into a
division and then claim that substitution of entitles GCC to ram  libgcc down
my throat. 

In freestanding program I do not want, and apparently the linux kernel, does
not want libgcc painted any color. It is our prerogative to specify the
operations we want. In hosted programs it might not be worthwhile fighting
aganst the under-handed way libgcc is dragged (remember ldd does not show its
use). Even the US Supreme Court looks at the drafting process preceeding the
Constitution and any laws passed by Congress. Now the below Is what boud the
C99 committee in drafting the standard.

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.


They say it much batter than I ever could. I found it when looking for the
price of the official C99 Standard. I am leaving for the benefit of less
fanatical people.


-- 

malitzke at metronets dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494