Re: Computer architects leaving Intel...

The clang/gcc maintainers' POV violates the first part of Postel's Law:
 > Be liberal in what you accept, and conservative in what you send.
Life would be a lot easier if they just provided a -WUB option that warns and explains *any* construct that the compiler may regard as UB.
(The various already existing options, e.g. -Wnull-dereference etc., and the most deviant outgrowth, -fsanitize=... are *not* reliable; the compiler happily optimizes whole execution paths away and does not tell about it with any syllable).
On 30.08.24 19:58, Anton Ertl wrote:

David Brown <david.brown@hesbynett.no> writes:

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.

 GCC and Clang/LLVM are distributed in source code, and given that
their maintainers find it ok to compile programs to arbitrary code if
they do not meet your expectations, one should expect that they do not
rely on behaviour that is not specified and documented, and never have
(at least not since adopting this attitude).  But even they are not up
to the task.  As John Regehr writes
<https://blog.regehr.org/archives/761>:
 |LLVM/Clang 3.1 and GCC (SVN head from July 14 2012) [...] execute
|undefined behaviors even when compiling an empty C or C++ program with
|optimizations turned off.
 I am not surprised that nobody has risen to my challenge
<2017Aug18.152854@mips.complang.tuwien.ac.at>:
 |Write a proof-of-concept Forth interpreter in the language you
|advocate that runs at least one of bubble-sort, matrix-mult or sieve
|from bench/forth in
|<http://www.complang.tuwien.ac.at/forth/bench.zip>
 in the last 7 years.
 

It is, of course, a lot easier to write software that appears roughly
correct in the source code and passes its tests, than software that is
rigidly accurate.

 I never heard about "rigidly accurate" as a property of software
(except maybe numeric software).
 The practice is that software is either tested (the usual case) or
formally proved correct.  For a C program to be formally proved
correct would, dirst and foremost require a formal specification of C.
 

I see nothing wrong in blaming programmers for using "memcpy" when they
should have used "memmeove" - it was those programmers that made the
error.

 I did not expect *you* to see what's wrong.  But I hope that I never
have anything to do with anything that you programmed.
 What's wrong with blaming the application programmers is that it does
not help the users of the binary that misbehaved after glibc was
"up"graded.  It also does not help users who have a no-longer
maintained piece of source code that used to work with earlier
versions of glibc, but now acts up on some hardware.  Sure, there are
workarounds, but first the user would have to understand the problem.
 - anton

--
Bernd Linsel