Path: ...!news.misty.com!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Tue, 3 Sep 2024 10:10:20 +0200
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <vb6g9d$396lj$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>
 <86ed61pfus.fsf@linuxsc.com> <vb68c2$3833i$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 03 Sep 2024 10:10:21 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="93d7d6b8e3b40fe75b60c4526d162769";
	logging-data="3447475"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/y+wi3aOXQnAkovJ2Slp7DnqfA87Hulfs="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:9fhr6O2dzpRDVMqG5MF10R6JrKg=
Content-Language: en-GB
In-Reply-To: <vb68c2$3833i$1@dont-email.me>
Bytes: 4264

On 03/09/2024 07:55, Thomas Koenig wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
> 
>> My suggestion is not to implement a language extension, but to
>> implement a compiler conforming to C as it is now,
> 
> Sure, that was also what I was suggesting - define things that
> are currently undefined behavior.
> 
>> with
>> additional guarantees for what happens in cases that are
>> undefined behavior.
> 
> Guarantees or specifications - no difference there.
> 

I personally think that - for the most part - that would be a really bad 
idea.  I am not in favour of arbitrarily defining the behaviour of 
something that has no sensible correct behaviour.  If the code flow 
reaches something that is run-time UB, the code is wrong or has been 
used incorrectly (i.e., the calling code, or user, or something else has 
made a mistake).  No possible handling of the UB will result in correct 
results.

It is sometimes possible to have damage limitation, such as exiting the 
program quickly with an error message rather than corrupting files, 
opening security breaches, etc.  But that is always context specific - 
stopping the program with an error message is fine for many PC programs, 
but less ideal for a flight control system.


There are some languages that have integrated error handling, and can 
sensibly have checks as a natural part of the language and the code.  C 
is not such a language.  Let C remain a language where the programmer 
has control, and where checks are done manually or they are not done at 
all.  People who don't want that, should use other languages that give 
them what they want.  UB in C is a /feature/, it is not a problem. 
Trying to remove UB (by specifying more behaviour) reduces the power of 
the language, and reduces the power of tools for the language, often for 
downright silly results (like wrapping integer overflow).

But if people want a compiler that has extra guarantees and 
specifications for behaviour in cases of UB, then those already exist - 
"gcc -fsanitize=undefined" would be a good example.  Of course such 
tools could be improved in a variety of ways.


(There are a few situations where UB in C could be diagnosed at 
compile-time, which are probably historical decisions to avoid imposing 
too much work on early compilers.  Where possible, UB that can be caught 
at compile time, could usefully be turned into constrain violations that 
must be diagnosed.)