Re: Computer architects leaving Intel...

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.)