Re: bart again (UCX64)

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups	comp.lang.c
Subject	Re: bart again (UCX64)
Date	2023-09-13 15:44 +0100
Organization	A noiseless patient Spider
Message-ID	<877counnej.fsf@bsb.me.uk> (permalink)
References	(16 earlier) <udo4s3$17hu7$1@dont-email.me> <87ledcp05z.fsf@bsb.me.uk> <678354ed-d89c-4d45-adfd-1ded3d22eecan@googlegroups.com> <87ttrzo1zm.fsf@bsb.me.uk> <5e098055-c3bd-4f9c-984c-b4fdaf610adbn@googlegroups.com>

Show all headers | View raw

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Tuesday, 12 September 2023 at 16:17:18 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes: 
>> 
>> It is a mistake to link the error with the two behaviours. A single 
>> error can provoke either or neither behaviour, sometimes always or 
>> never. It's not uncommon for an error to go entirely unnoticed because 
>> the behaviour is always correct. Maybe the fix is to put in "return 0;" 
>> but that happens to be what is in this or that register on this C 
>> implementation on this hardware at the point where the call happens. 
>> 
>> This is not quibbling or sophistry. The errors are in the text and the 
>> behaviours are in the world. But We can only fix the text. That is the 
>> only way a programmer can alter the behaviour.
>>
> That is a fair point. You can have an error which in fact never provokes incorrect
> behaviour. For example to use sign() again, if we write it to return -1 or +1
> and forget the zero, it might well aways return zero when it falls of the end 
> for the case 0. It would be an error in the program text, but it would behave
> correctly.  
>>
>> > I can't 
>> > think of another behaviour that is erroneous but doesn't fall under 
>> > one of those two categories (though someone might be able to suggest 
>> > one).
>> I can (timeliness comes to mind) but that would be quibbling. The big 
>> issue is that I reject the notion that one error implies one of two 
>> behaviours. 
>> 
>> Why does this matter? Because it's just programming. There should be a 
>> specification where you have left a void for this mystery program. The 
>> life support system should be specified to provide timely and correct 
>> results to the oxygen valve or to stop in such a way to provoke other 
>> systems to trigger the alarms other wise. 
>>
> It's specified to always control the flow of oxygen, based on various
> readings it takes from sensors attached to the patient.

That might be the first specification, but it will get revised at the
first review before a line of code is written.

> If it stops controlling the flow
> of oxygen, that's very serious. The alarm goes off. The nurse should come. 
> But it's very much an emergency and undesired.

It might be very much desired considering the alternatives.  But the
point is that something needs to stated so that we know what to
implement.  You might assume that any sane programmer will, in effect,
be implementing my revised spec, but that's not how to do serious work.

>> Putting an abort() call and the end of sign(x) (if that is indeed what 
>> you are suggesting) is called meeting the specification. Of course 
>> there can be bugs (the call was missing at first) but that is just 
>> programming. There are, of course, thousands of other fixes.
>>
> Not. it's not meeting the specification.

Now there's a spec, and an impossible one at that!  In my remark I had
to guess what you want because it was, up to that point, unspecified.
(Or did I miss it?)

I think the impossible spec is not an accident.  You want the discussion
to be forced into the wrong result/no result divide, where I insist on
failure modes being specified because I want to focus on the
correct/incorrect divide.

>> That the author 
>> of sign(x) did not consider NaNs is no different to an author no 
>> different considering a factor 10^6 error in the flow rate, except that 
>> it's easier to avoid NaNs than it is to avoid simple typos.
>>
> sign() has a core domain which includes all the real numbers. You
> might know that none of the reals in the program can be lower than
> unity. But you can't sensibly trap such numbers and still call the
> function sign(). NaN isn't in the core domain.  We can sensibly say
> that sing(NaN) is NaN, or at a stretch, even 0. But we can also say
> that calling sign with NaN is to be considered a programming error.

I really, genuinely, have no idea what your point it.  You appear to
describing the basics of how one writes code, informally, with no clear
objectives in mind.  We could this, we could that: NaNs are in the
domain but not in the core domain.  We could return NaN or 0 or trap a
programming error if one is passed.

>> > You've been reading too much David Brown, and got infected. Anyone with 
>> > any experience in programming knows that often bugs are very simple and 
>> > obvious. Once you point them out. But highly qualified programmers still 
>> > make such mistakes.
>>
>> I don't believe DB thinks what you believe he does. I certainly don't 
>> think that. And I resent the notion that I have been "infected" by a 
>> bad thought, especially one I am sure you have made up out of thin air. 
>> Please acknowledge that I am perfectly aware that all programmers make 
>> mistakes. Without that, there is simply no point in continuing. 
>> 
> Fair enough. Unlike some other posters, you don't look for
> opportuniites to snipe.  If you think the NaN comparison error is too
> simple, you can always think of a way to make it a bit more subtle
> whilst still being bascially the same bug.

I am happy to stick with rather artificial examples, but you are not
getting to the point.  What is the bug?  Does the code somehow magic up
NaNs and if so from where?  Do you agree that one bug can produce many
different behaviours and at different times?  Do you accept that the
specification should say what happens when the sensors fail, or the
correct operation can no longer be guaranteed?  This discussion feels
like nailing a jelly to the fence.

> Similar errors do make their way into critical systems where the costs are 
> extremely high,  like spacecraft, and there have been reports.

Yes.  But what are you proposing to do about it that you think differs
from my methods?  My proposal is simple to state: minimise the chance of
errors in the program; that is cases where the program might not behave
as specified.  This can include improving the specification as well as
the code.  Possibly the only disagreement (if you will accept the
correct/incorrect classification rather than yours) is that sound
reasoning plays a part in my proposal.  I would happily include a
rigorous code review to ensure that, say, NaNs and Infinities never
occur.  These are not magic quantities but specific values that arise in
tightly controlled and well-specified situations.  Such a review is no
harder than one that tries to ensure that the value sent to value
controller is within the correct technical bounds.

>> The issue, which you don't seem to be addressing, is what we do about 
>> it. We don't just look at code and say, "that looks like a bug, let's 
>> put an abort() in there". The whole software development process has to 
>> be geared to minimising the ways in which a program text might fail to 
>> behave as required. For some programs, the specification is to generate 
>> correct results or to fail hard. For others it is to keep going at all 
>> costs. 
>> 
>> One technique that can help (in one small area) is to try to ensure that 
>> there are no NaNs. That can be simpler than putting in tests or other 
>> actions all over the place in case one has just popped up like a genie 
>> from a lamp. Note that I am not saying there can't be bugs, but I would 
>> bet any money that a code review for "don't ever generate a NaN" is 
>> easier and more effective than a code review for "check everywhere it 
>> might matter for NaNs and act accordingly".
>>
> But in this case, readsensors() returns a NaN if the sensors have no data
> (not working, or maybe not enough time lag between calls). That's a reasonable
> interface. So we can't say "exclude all NaNs for the code". But a NaN still
> shouldn't be passed to sign(). That's the programming error.

OK.  There's a bit more detail.  But I can't address it because you
don't say what should happen.  Anything I propose will be met by "no,
that's not meeting the specification".

>> > No we can't use Haskell.
>> That's a shame. The Glasgow Haskell compiler reports that in 
>> 
>> sign :: Double -> Int 
>> sign x | x < 0 = -1 
>> | x == 0 = 0 
>> | x > 0 = 1 
>> 
>> the guards are non-exhaustive. 
>> 
> That's very good.

As it happens (thanks, David) it isn't.  The warning can include false
positives because the analysis is crude.  Of course it still helps if
you want look for possible problem areas because there are no false
negatives, but it's not doing what I hoped.

-- 
Ben.

Thread

Re: bart again (UCX64) candycane@f172.n1.z21.fsxnet (candycane) - 2023-09-06 19:53 +1300
  Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-07 12:00 -0700
    Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:33 -0700
      Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-07 20:55 -0700
        Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 22:16 -0700
          Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-08 07:09 +0000
            Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 10:10 +0200
              Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 01:30 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:26 +0200
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 10:44 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 13:26 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:57 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:36 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 18:19 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 13:28 +0200
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-10 13:20 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 15:19 +0200
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-10 16:07 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 18:33 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-10 15:44 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 18:36 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:48 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 19:04 +0200
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 02:47 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:03 +0200
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 16:06 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-09 01:52 +0100
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 18:16 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-09 21:31 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 12:03 +0200
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-10 21:36 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 08:51 +0200
                Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-10 23:59 -0700
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 01:01 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 11:17 +0200
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 03:16 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 14:58 +0200
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 06:35 -0700
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-11 14:13 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 16:24 +0200
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-11 14:55 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 16:42 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-11 14:29 +0000
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-11 11:25 +0100
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 03:59 -0700
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-11 13:57 +0000
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 09:52 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 16:07 +0200
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-11 16:26 +0100
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-11 16:47 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 19:14 +0200
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-11 22:30 +0100
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-11 23:07 +0100
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-11 23:31 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-12 09:18 +0200
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-12 03:01 +0100
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 10:08 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-11 23:18 +0100
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-11 23:37 +0100
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 15:46 -0700
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-11 23:40 +0000
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-12 01:50 +0100
                Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-11 17:59 -0700
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-12 01:03 +0000
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-12 02:39 +0100
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-12 11:28 +0100
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-12 14:49 +0100
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-12 15:18 +0100
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-12 03:58 +0100
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-12 02:25 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-12 16:17 +0100
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-12 17:28 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-12 21:07 +0200
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-13 03:01 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 09:38 +0200
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 10:00 +0200
                Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-19 05:22 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-19 14:29 +0100
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-13 13:35 +0100
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-13 20:48 +0100
                Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-19 05:53 -0700
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-12 09:33 -0700
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-12 16:48 +0000
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-12 10:57 -0700
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-12 18:07 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-12 21:23 +0200
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 02:07 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 12:43 +0200
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 04:04 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 14:07 +0200
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 01:47 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 13:02 +0200
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 04:45 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 14:36 +0200
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-13 13:43 +0000
                Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-13 11:10 -0400
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-13 17:12 +0000
                [meta] spam in thread Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 11:22 -0700
                Re: [meta] spam in thread Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-13 18:40 +0000
                Re: [meta] spam in thread Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 11:48 -0700
                Re: [meta] spam in thread David Brown <david.brown@hesbynett.no> - 2023-09-13 21:01 +0200
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-13 19:58 +0100
                Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-18 12:36 -0700
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-18 13:40 -0700
                Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-20 19:43 -0700
                Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 20:14 -0700
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-20 22:10 -0700
                Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-01 11:03 -0700
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 07:39 -0700
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-13 15:18 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 18:39 +0200
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-13 15:44 +0100
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 08:42 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-13 22:35 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 18:49 +0200
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 15:40 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-12 03:36 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-12 12:58 +0200
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-12 12:49 +0200
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-12 12:52 +0100
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-12 05:22 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-12 15:05 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 02:17 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 14:44 +0200
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-08 14:36 +0000
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:50 +0000
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-09 15:40 +0000
          Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 09:57 +0200
          Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-09 10:23 -0700

csiph-web