Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Thu, 5 Sep 2024 15:08:44 +0200
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <vbcags$bd22$1@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> <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me>
 <vb00c2$150ia$1@dont-email.me>
 <505954890d8461c1f4082b1beecd453c@www.novabbs.org>
 <vb0kh2$12ukk$1@dont-email.me> <vb3smg$1ta6s$1@dont-email.me>
 <vb4q5o$12ukk$3@dont-email.me> <vb6a16$38aj5$1@dont-email.me>
 <vb7evj$12ukk$4@dont-email.me> <vb8587$3gq7e$1@dont-email.me>
 <vb91e7$3o797$1@dont-email.me> <vb9eeh$3q993$1@dont-email.me>
 <vba56o$3te58$3@dont-email.me> <20240904235358.00001101@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 05 Sep 2024 15:08:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="622309b8b3e203ac6e38dece30d12fb2";
	logging-data="373826"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+tVW8vak27kSxW0Kk1AzKbpKCcMMmvQJc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:0bLjQqzueYmK6KUdxgGlI4ygdNg=
Content-Language: en-GB
In-Reply-To: <20240904235358.00001101@yahoo.com>
Bytes: 3978

On 04/09/2024 22:53, Michael S wrote:
> On Wed, 4 Sep 2024 17:25:44 -0000 (UTC)
> Thomas Koenig <tkoenig@netcologne.de> wrote:
> 
>> David Brown <david.brown@hesbynett.no> schrieb:
>>
>>> I'm all in favour of temporarily having checks for overflow (and
>>> other errors) during debugging, but I am sceptical to having
>>> distinct debug/release builds.  It encourages people to use debug
>>> builds during development, bug hunting and testing, then when all
>>> looks good they switch to release build and deploy it.  I prefer a
>>> single build, and enable run-time checks on parts of it if and when
>>> necessary.
>>
>> Wise man once said...
>>
>> # It is absurd to make elaborate security checks on debugging runs,
>> # when no trust is put in the results, and then remove them in
>> # production runs, when an erroneous result could be expensive or
>> # disastrous. What would we think of a sailing enthusiast who wears
>> # his lifejacket when training on dry land, but takes it off as soon
>> # as he goes to sea?
>>
>> (C.A.R. Hoare, in "Hints on Programming Language Desin)
> 
> Wise man was wrong.
> Range check are not similar to live jackets. They do not turn incorrect
> program into correct one.
> 

Wise man was right.  Range checks are not intended to turn incorrect 
programs into correct ones - they are for damage mitigation.  Life 
jackets don't stop you falling overboard, they stop you drowning if you 
/do/ fall overboard.  The context of the quotation was "security 
checks", which is different from debugging and fault-finding.


For some kinds of software, you have to think about what can go wrong 
outside the context of software bugs, and what can be done about it - 
such as damage limitation.  There can be external effects such as 
malicious or accidental corruption of data, hardware failures, etc. 
These are outside the scope of C, and need special treatment such as 
using "volatile" to inform the compiler that something has observable 
behaviour, or using inline assembly or intrinsic functions for fine 
control.  And you have to accept that usually, there is no way to handle 
these things entirely in software.