Re: Computer architects leaving Intel...

On 30/08/2024 20:34, Stefan Monnier wrote:

If you want to write reliable code that can be distributed as source and
compiled by any conforming C/C++ compiler, you need to be very sure that you
avoid relying on behaviour that is not specified and documented. You need to
write correct code.  That means if you want to copy some memory with
overlapping source and destination arrays, you use "memmove" - the function
for that purpose.  You don't use "memcpy", since it is specified explicitly
as requiring non-overlapping arrays.

 The difficulty here is that the tools provide very little help for that,
because all too often it's virtually impossible for the tools to
understand that this particular code can/will hit UB.
 

Yes, that is true.  And in such cases there is no way for a compiler to "optimise on the assumption of no UB", since it does not know that there will be, or could be, UB.  So Anton has nothing to fear there.  Bernd, on the other hand, might be disappointed - there is also no way for the compiler to warn that the code might have error or UB.

So it's all up to the programmer, who often doesn't know either.
Other than using CompCert, I don't know of any reliable way for
a programmer to make sure his C code does not suffer from UB.
 

There is no full-proof or complete method for C.  There are other language for which formal methods can come closer to proving the correctness of the code, but for most practical cases this is infeasible.
The best you can do, as a programmer, is to learn the language as well as you can, write code carefully, and use whatever help you can get that is within budget - including linter tools, code reviews, test setups, and so on.  You can come a long way using good free tools such as gcc and clang, including their extensive compiler warnings and their sanitizers for run-time checking and testing.
No one claims that writing good, working code is easy.