Re: Computer architects leaving Intel...

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.

The standard could always define previously undefined behavior in
subsequent versions.  (Adding a new feature is mostly that).

However, the main problem I see is that of defining that subset
or version or whatever you want to call it of C that you (generic
you) want implemented.  It could be defined as an extension (or
restriction, if you will) of the C standard, with additional
rules.

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.