Path: ...!news.mixmin.net!news.swapon.de!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sat, 7 Sep 2024 14:30:30 +0000
Organization: Rocksolid Light
Message-ID: <e6108b1448a50d0f288a32fb6e8f739f@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> <b5012b806aa6f100c84907bc544ec59f@www.novabbs.org> <86jzfnmv0d.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="1189011"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$w56yvQh6iaCLC3yfZT9lxe.MWIIUcgsCbnjoygcHXdOgBUO6ObSEa
Bytes: 5534
Lines: 86

On Sat, 7 Sep 2024 13:52:02 +0000, Tim Rentsch wrote:

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

With it "being difficult" to determine when an integer overflow
has occurred in may architectures, it is unlikely that integer
overflow could ever be put into the C standard.