Path: ...!3.eu.feeder.erje.net!feeder.erje.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: Sun, 08 Sep 2024 09:19:13 -0700
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <86jzfmktj2.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> <86ed61pfus.fsf@linuxsc.com> <vb68c2$3833i$1@dont-email.me> <vb6g9d$396lj$1@dont-email.me> <ljp1kvFdbt2U1@mid.individual.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sun, 08 Sep 2024 18:19:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f4e3787f228c748b74e6d718e0ca7324";
	logging-data="2096196"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/uomnpGM8uJuyRwf2zP2rN7qQe0EoIkQ0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:EidDVX+eNBOFLPxOOtj+o0rVenE=
	sha1:Gok3SVphdYtPa2w6xO0jc6RsUTE=
Bytes: 4796

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> On 2024-09-03 11:10, David Brown wrote:
>
>    [snip]
>
>> (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.)

A thoughtless, knee-jerk reaction, ending in a wrongheaded
conclusion.

> The problem, as you of course know, is that the "can" in "can be
> caught at compile time" depends on the amount and kind of analysis
> that is done at compile time -- some cases of UB "can" be caught at
> compile time but only by advanced and costly analysis.  If the language
> standard requires that such things /must/ be detected by the compiler,
> it can place quite a burden on the developers of conforming compilers.

That is one problem.

> As I understand it, current C compilers detect UB mostly as a side
> effect of the analyses they do for code optimization purposes, which
> vary widely between compilers, and so the UB-detections also vary.

There are different kinds of undefined behavior;  some are easy
to detect, others require more extensive analysis.  In the second
category the analysis usually is approximate rather than exact;
false positive cases need to be weighed against false negative
cases, looking for the right balance, and very often it happens
that neither of those is zero.  Obviously any requirement that a
mandatory diagnostic be issued should have no false positives,
which often means doing a different analysis.  More work.

Another problem is that just the act of specifying the condition under
which a diagnostic is required means a lot of work and a non-trivial
amount of additional text needed in the C standard.  If someone is
interested to investigate this a good place to start is the Java
standard, where there are specific rules for deciding if variables are
all initialized before any use.  Alternatively look in the C standard
at the formal definition of 'restrict'.  Besides being hard to write,
both of these are quite difficult to read and understand.  Even more
of those?  No thanks.

Let me add, it is not always a good idea to require a diagnostic in
cases even when it is 100% certain that there is undefined behavior.
Unfortunately it seems there are a fair number of people who don't
get this.

> This issue (compile-time detection) has now and then been discussed in
> the Ada standards group.  Given the currently low market penetration of
> Ada, the group has been reluctant to require too much of the
> compilers, and so the more advanced UB-detecting tools are
> stand-alone, such as the SPARK tools.

I'm all in favor of static analysis.  And I don't mind if compilers do
it (selectively), instead of or in addition to stand-alone tools.  But
there is a huge chasm between saying compilers /can/ do it and saying
compilers /must/ do it.  Crossing that chasm is a bridge too far.