Re: Computer architects leaving Intel...

Thomas Koenig <tkoenig@netcologne.de> writes:

I'm responding here to one part of your posting.  I
may respond to the other part at a later time.

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>

In some sense I am
agreeing that the problem here is caused by the C standard, not by
it changing in different versions but by it giving too much freedom
to implementors for so-called "undefined behavior".  Sadly the
standardization process seems to have been taken over by compiler
writers, so the best advice I can offer is to join the ISO C
committee and start voting out the lunacy.
>
Alternatively I suppose
one could start up a competitive effort to gcc and clang, and offer
a compiler that doesn't engage in such shenanigans unless told to do
so (and told specifically), and then try to get developers to switch
to sane C in preference to the ever-increasingly insane C that is
most commonly used today.

>
The specification needs to come first!  Right now, compiler writers
have a specification, the standard, which they generally follow
(modulo bugs and extensions).  You have to give them another,
supplemental specification to follow if you want any chance
of success.
>
But writing such a specification is a lot of work, very hard work,
and needs a lot of discussion.
>
"Don't do this" or "don't do that" is not sufficient.  Maybe you,
together with like-minded people, could try formulating some rules
as an extension to the C standard, and see where it gets you.
Maybe you can get it published as an annex.
>
If it gets accepted by a wide community, then a branch trying to
implement that particular version in either gcc or clang (or
both) could have a certain chance of being implemented by the
main compilers.

My suggestion is not to implement a language extension, but to
implement a compiler conforming to C as it is now, with
additional guarantees for what happens in cases that are
undefined behavior.  Moreover the additional guarantees are
always in effect unless explicitly and specifically requested
otherwise (most likely by means of a #pragma or _Pragma).
Documentation needs to be written for the #pragmas, but no other
documentation is required (it might be nice to describe the
additional guarantees but that is not required by the C
standard).

The point is to change the behavior of the compiler but
still conform to the existing ISO C standard.