Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Fri, 6 Sep 2024 18:17:50 +0000
Organization: Rocksolid Light
Message-ID: <b5012b806aa6f100c84907bc544ec59f@www.novabbs.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1089394"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$DcGu9piFODR9XXmf82je1e8i7JeZshjiLSr3w60QDdqw5P5y4JICS
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4963
Lines: 77

On Fri, 6 Sep 2024 13:37:13 +0000, Tim Rentsch wrote:

> 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.  (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.

It is also possible if a == INT_MAX that the exception will
transfer control to a signal handler to do some SW orchestrated
recovery.

> Let me be clear that I have not thought through all the details
> about exactly what the rules are or how they might be put into
> effect.  Hopefully though my comments here give you a better
> sense of the direction meant to be suggested.