Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sat, 7 Sep 2024 07:26:51 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <vbgv7r$18q47$1@dont-email.me>
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>
 <vb58i5$303nc$1@dont-email.me> <868qw4oqd2.fsf@linuxsc.com>
Injection-Date: Sat, 07 Sep 2024 09:26:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5a0d26841d8e5191717c16dfbd051b00";
	logging-data="1337479"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19CboFKZ1svqK1dHTG+nwT0gEOrp5GnVOU="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:PSr18rktGdu56CksSXDXuUfN6cM=
Bytes: 5247

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>> Thomas Koenig <tkoenig@netcologne.de> schrieb:
>>
>>> "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.
>>
>> Hm... putting some thought into it, it may be a good first step
>> to define cases for which a a diagnostic is required;  maybe
>> "observable error" would be a reasonable term.
>>
>> So, put "dereferencing a NULL pointer shall be an observable
>> error" would make sure that no null pointer checks are thrown
>> away, and that this requires a run-time diagnostic.
>>
>> If that is the case, should dereferencing a member of a struct
>> pointed to by a null pointer also be an observable error, and
>> be required to be caught at run-time?
>>
>> Or is this completely the wrong track, and you would like to do
>> something entirely different?  Any annex to the C standard would
>> still be constrained to the abstract machine (probably).
>
> The idea is not to make more of the language defined but to give
> less freedom to cases of undefined behavior.

That sentece makes no sense to me.

Behavior is defined by the standard, by the compiler documentation,
by other standards (such as OpenMP) or it is undefined.

"Giving less freedom" has no difference from defining.

>(It might make
> sense to define certain cases that are undefined behavior now but
> that is a separate discussion.)  Let me take an example from
> another of your postings:
>
>   int a;
>
>    ...
>
>   if (a > a + 1) {
>     ...
>   }
>
>
> Stipulating that 'a' has a well-defined int value, what behaviors
> are allowable here?
>
> If a < INT_MAX, the behavior is the same as replacing the if()
> test with 'if(0)'.  If the compiler can accurately deduce that
> the condition 'a < INT_MAX' will hold in all cases then the if()
> can be optimized away accordingly.
>
> If a == INT_MAX, one possibility is that code is generated to
> evaluate the addition and the comparison, and the if-block is
> either evaluated or it isn't, depending on the outcome of the
> comparison.  Important:  the compiler is disallowed from drawing
> any inferences based on "knowing" the result of either the
> addition or the comparison;  code must be generated under a "best
> efforts" umbrella, and whatever the code does dictates whether
> the if-block is evaluated or not, with the compiler being
> forbidden to draw any conclusions based on what the result will
> be.
>
> If a == INT_MAX, it also should be possible for the addition to
> abort the program.  Here again the compiler is disallowed from
> drawing any inferences based on knowing this will happen.  To
> make this work the rule allowing "UB to travel backwards in time"
> must be revoked;  unless a compiler can accurately deduce that a
> given piece of code cannot transgress into UB then other code in
> the program must not be moved (either forwards or backwards) past
> the possibly-not-well-defined code segment.

After thinking about this for a time, what you want looks a lot
like volaitle.

Is there any requirement that you can think of that would not
be fullfilled with "volatile int a"?

Is there anything with "volatile int a" that you do not want?

If volatile is close to what you want, then this would be
straightforward to incorporate into an existing compiler such as
gcc, just add an option which declares every variable in the C
front end volatile, weed out the resulting bugs (yes, that is a
mixed metaphor) and be done.