Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: "RESET"
Date: Sat, 24 May 2025 22:58:45 -0700
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <100ubin$17n5c$1@dont-email.me>
References: <100thgs$v8cm$1@dont-email.me>
 <MPG.429c5cc5fbe9667698a03f@news.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 25 May 2025 07:58:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="672de9e7a519c663ff2d3c552f49d2c5";
	logging-data="1301676"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+fbxfZ6uAn4rNOuMHaxtcx"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:nphEgACYF917Crrdi0Ug+LGGh+U=
Content-Language: en-US
In-Reply-To: <MPG.429c5cc5fbe9667698a03f@news.eternal-september.org>

On 5/24/2025 8:47 PM, Ralph Mowery wrote:
> Sometimes it is the user that is lacking.  Such as forgetting a
> password. Maybe putting the device in the wrong mode and can not
> remember how to get it out of that mode.

And cycling power won't suffice?

> With the many lines of code it  is impossiable to check out every
> possiale combination of things that could ge wrong in a reasonable time.

You let the code catch the mistakes.  Any time two pieces of
code ("modules") interact, a formal interface SHOULD exist that
defines the contract that both parties will observe.  Instead
of just HOPING that the other guy is holding up his end of
the contract, write code to CATCH those times when he clearly isn't.

When you find such an instance, "something is wrong"; either an
assumption made at design time, a bug in an implementation, or
a hardware fault that has corrupted data or execution (any product
that uses memory is subject to all sorts of faults; the more memory
and higher frequency of access then the greater the *likelihood*
of errors).

A staple of robust software development practices is formalizing
these interfaces and adding invariants to enforce them at run time
(these things almost never have a significant impact on performance
if implemented properly).

You know to check before dividing a value into another (divide by
zero).  Have you asked yourself WHY the possibility of "zero"
exists in your code?  Or, "negative time"?   Have you modeled
the problem correctly?

> While not really much of a chance but in the eairly days bits could be
> randomally changed by stray radiation.

Errors can be induced from the "traffic" within a device
(read and write disturb) without having to worry about radiation.
(thought there have been some studies that show a positive correlation
of error rates with elevation)

Hardware isn't as reliable as folks would like to think.
So, you have to design algorithms and styles that catch
the hardware when it is misbehaving (otherwise, you will
naively blame it on a software "bug" -- because you
don't understand how the hardware is failing nor have
tools to MEASURE those failures)