Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Fri, 30 Aug 2024 21:08:09 +0200
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <vat5ap$jthk$2@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 30 Aug 2024 21:08:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="49a681f7d24b901247f6f16905e4a2c8";
	logging-data="652852"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/FttSVVDptkHgmcS8zXT9O"
User-Agent: Betterbird (Linux)
Cancel-Lock: sha1:hgmqYoMWn1NjWQ4MFW44lKBgt8I=
Content-Language: en-US
In-Reply-To: <2024Aug30.195831@mips.complang.tuwien.ac.at>
Bytes: 4267

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