Path: ...!news.mixmin.net!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: Sat, 07 Sep 2024 06:52:02 -0700
Organization: A noiseless patient Spider
Lines: 81
Message-ID: <86jzfnmv0d.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> <vb58i5$303nc$1@dont-email.me> <868qw4oqd2.fsf@linuxsc.com> <b5012b806aa6f100c84907bc544ec59f@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sat, 07 Sep 2024 15:52:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="15cdd4985ebd3d04d209b9ff3a6e4cfe";
	logging-data="1472649"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18cyqnrSqYyKnUqq/1v2ZpMlcxPzSvJQz4="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:m5VmXvKvGElnlUiMtK8dkUbf6yY=
	sha1:yWCD2zZ1lMnqjiYprlXhp10Q7BQ=
Bytes: 5233

mitchalsup@aol.com (MitchAlsup1) writes:

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

Philosophically this reaction doesn't fit with the others.  Assuming
for the sake of discussion that raising an implementation-defined
signal is an important behavior to support, it should go into the
C standard in a different way than making it part of the "limited
undefined behavior" idea outlined above.