Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Fri, 30 Aug 2024 17:58:31 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 56
Message-ID: <2024Aug30.195831@mips.complang.tuwien.ac.at>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me>
Injection-Date: Fri, 30 Aug 2024 20:24:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0f802512a75abac598a61593e1338edd";
	logging-data="636492"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18ivkmT8UQHhOd7Qlqu5UXs"
Cancel-Lock: sha1:Idvr7njKHAb5zELoyBWeFVm7KS0=
X-newsreader: xrn 10.11
Bytes: 3557

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
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>