Path: ...!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: Wed, 4 Sep 2024 01:19:36 +0200
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <vb85i8$3gq7e$3@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>
 <vb6g9d$396lj$1@dont-email.me> <vb7gf3$3dm1b$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 04 Sep 2024 01:19:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="007bf4bb57fea4fb73ad9dc6d5dccf66";
	logging-data="3696878"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18r3gfEmwAF4mrYdQ26ED3gwhDU1qO/0ys="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Y68aMn4RJor8WTHx0OZKZrX6oW8=
Content-Language: en-GB
In-Reply-To: <vb7gf3$3dm1b$1@dont-email.me>
Bytes: 3093

On 03/09/2024 19:19, Bernd Linsel wrote:
> On 03.09.24 10:10, David Brown wrote:
> 
> snip 8< - - - - - - - -
> 
>> (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.)
> 
> And exactly these are the situations that I'd like to be warned from, 
> rather than the compiler making up something without telling.
> 

Some of those /are/ warned about by compilers (but I'd rather the 
standards said that they were errors).  But in general, many can be 
handled by good development practice and compiler warnings.  Still, 
compilers could always get better!

One thing that could make a big difference, I think, is to drop the 
compilation model of each translation unit being compiled to a binary 
object independently, with only a minimal amount of information for 
linking.  Link-time optimisation allows for many extra checks, not all 
of which are currently implemented AFAIK.  For example, it should be 
possible to check that external declarations and definitions match up 
correctly across modules - that's currently UB and rarely checked.