Re: Computer architects leaving Intel...

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.