Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 02 Sep 2024 20:37:31 -0700
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <86ed61pfus.fsf@linuxsc.com>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me> <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me> <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me> <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me> <vb2hir$1ju7q$1@dont-email.me> <8lcadjhnlcj5se1hrmo232viiccjk5alu4@4ax.com> <vb3k0m$1rth7$1@dont-email.me> <17d615c6a9e70e9fabe1721c55cfa176@www.novabbs.org> <86v7zep35n.fsf@linuxsc.com> <20240902180903.000035ee@yahoo.com> <86r0a2otte.fsf@linuxsc.com> <vb50cm$2uttr$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 03 Sep 2024 05:37:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5dc3c968fdc353e2fd687882edf89fc4";
	logging-data="3360519"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+7JTq16CYjr9Rb6UM/efvjonHeLlZQh1U="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:QcMiJzhsCc+fvt24p+rGb9jw+7Y=
	sha1:sjbvXTBkdet+W8FqpkZxbMSciNA=
Bytes: 4023

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.