Path: ...!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 08:53:28 +0200
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <vb9058$3nlvo$2@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>
 <vb85i8$3gq7e$3@dont-email.me>
 <9f97563d70c3a282b12466f531c26c5f@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 04 Sep 2024 08:53:29 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0366692407b62e2f3ab0bc1ba1697c81";
	logging-data="3921912"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/nyNOi2BOY1xYirwzIe+fl+K3PSBsJ9Yc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:+gbRLad3RnxM2kjNE3l+oUa7sh8=
Content-Language: en-GB
In-Reply-To: <9f97563d70c3a282b12466f531c26c5f@www.novabbs.org>
Bytes: 4460

On 04/09/2024 03:54, MitchAlsup1 wrote:
> On Tue, 3 Sep 2024 23:19:36 +0000, David Brown wrote:
> 
>> 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!
> 
> Something that might be an error in a 32-bit machine may not be
> an error in a 36-bit {48, 64, 72} machine.
> 
>> 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.
> 
> How does one call fprintf() under those rules ??

Untyped vararg functions are a big risk factor for programming and are 
always difficult for static (or run-time) checking.  The best you can do 
is limit them to the standard ones (the printf family is very useful), 
make sure you are always using declarations from common headers rather 
than "home-made" declarations, and use the tools you can (such as gcc 
and clang's format attribute checks).

There will never be a way to do full automatic checking of code 
correctness.  But the more mistakes that can be caught automatically, 
the better.  Modern tools can catch more than older tools, and there is 
scope for them to catch even more.  (Though it can sometimes be 
surprising how difficult it can be to add seemingly obvious warnings to 
compilers - the way the different analysis and optimisation passes are 
divided can mean critical information is lost or too inefficient to track.)