Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #175419

Re: bart again (UCX64)

Show all headers | View raw

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

I'm going to skip to the parts that I feel I can get some purchase on...

>> > 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.

> On Wednesday, 13 September 2023 at 15:44:37 UTC+1, Ben Bacarisse wrote:

>> 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.
>>
> The spec is int sign(double x) return -1 if x is negative, 1 if x is positive,
> and 0 if x is zero.  
> Any function which obeys that specification can legitimately be called
> "sign".
> So int sign( return x/fabs(x);} would not be sign(), because 0 isn't being
> handled correctly. return x ? x/fabs(x) : 0; would however be sign(). It won't
> work for infinities, but they aren't in the core domain. 
> Similarly
> int sign(double x)
> {
>     if (isnan(x))
>        return 2;
>     ....
> } 
>
> is sign(). NaN isn't in the core doman of sign(). We can legitimately say that
> "calling sign() with NaN is undefined". Nowever NaN is is the domain of sign(),
> just as infinites are. The sign of not-a-number is surely not a number. But we
> dont have to handle all the odd cases to implement what we can reasonably
> term "the function sign()". 
> Now if we know that NaNs can only be passed to sign() as the result of a 
> programming error, we can exploit this to trap the errors. If isnan(x),
> print out various diagnostic messages.
>
> However lets say that, in our program, we know that not only must a NaN represent
> a programing error. No real value can go out of the range -100 to 100. If it does,
> that must also be a bug.
> So can we write
>
>  int sign(double x)
> {
>     if (x < -100 || x > 100)
>        abort();
> }
>
> Thje answer is, no we can't. -101 is in the core domain of sign(). If we don't return
> -1 ofr it, we should no longer call the function sign().

I started to reply to some of this but I had to keep picking my jaw up
from the ground.  What is this company?  How do they hire programmers?
What processes do they have for ensuring code quality?

I suspect the trouble here is you are not playing this game properly.
It's a made-up scenario, but we (you and I) have to play as if it were.
That would mean I could reasonably step in above and say that, as
manager or reviewer, the "spec" for sign(x) would have been rejected out
of hand.  For one thing, "negative" is clearly ambiguous and "is" should
generally be avoided in any function using floating point.

Now, for small functions, the code can be taken to be the spec, and
provided there was good internal documentation (just a few lines of
comment about it oddly not covering the argument domain) I would accept
the rather odd code you first posted but I'd insist on an assert at the
top for testing.  But since we need this function to get accepted
without that, let's assume I was holiday and the reviewer did not insist
on the assert.

By the way, I try to use "we" only when I an referring to the
participants in a conversation.  For the record, almost nothing you
wrote above that used "we" includes me.

>> 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.
>>
>  In this case, the sensor had no data. So readsensors() returned NaN,
> as it was specified to do. And there is a function called
> handlesensorfailure() which is designed to cope with this
> situation. So correct code is to branch on the return result, and if
> it is NaN, call the function which copes with no data. If it is not
> Nan, call sign() with the result to decide whether to increase or
> decrease the oxygen flow.  Simple, unexceptional, non-contrived
> requirements.
>
> Unfortunately, in this case, the programmer was asleep, and instead of
> writing
> if (isnan(sensor_value)) 
>     handlesensorfailure();
> else
>    delta_oxygen_output = sign(sensor_value) * step;
>
> he wrote
>
> if (sensor_value == NaN)
>    handlesensorfailure();
>  else
>    delta_oxygen_value = sign(sensor_value) * step;
>
> Now obviously the intellectually challenged will say "that bug could
> never occur in a safety citical enviornment". And they may well be
> right. So make it the same underlying mistake but more subtle. These
> things can and do occur.

Did this code pass code review?  Did the reviewer see the results of the
unit tests?  Are they all interns?  Does the team need to hold it's hand
up and admit that this product won't be ready as everyone from the
project manager down needs to go on a few basic training courses?

> The question is how to write sign().

Is it?  Why is that the question?  Sign has been specified for normal
numbers, subnormal numbers, signed zeros and infinities.  It's fine
(though peculiar).  You don't go fixing a bug in one place by changing
agreed and working code elsewhere.

Actually question is how can the team be trained in writing unit tests
before the company is sued into oblivion.

> It is called only once in the program. It can never
> be passed a NaN. In the plan. In reality, it is passed a NaN.

It is specified, documented and working.  I would not advise changing
it.

But I don't know how we got to this point in the game.  Has the bug been
found yet?  If so, why is changing 'sign' even being considered?  And if
it has not been found, why is changing 'sign' even being considered?
(You might want to delay answering this until later as I ask the same
question again in relation to processes.)

>> > 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. 
>>
> Your method is to wave a magic wand and make the error go away.

Absolutely not.  It's not magic.  It's about well-written specs, good
internal documentation, thorough unit tests, careful code review, sound
integration tests and rigorous code management.  But a problem has
slipped through because I was away and someone did not insist on a
function asserting its pre-conditions during testing.

> And of course it should be caught by testing.

It /will/ be found in testing.  You can't wave your hand and say
"imagine there's a bug that did not get found in testing" because
although we know such things do occur, to discuss what can be done about
them we need a plausible example.

> In fact the compiler
> should warn. But however rigorous your testing, however carefully you
> adhere to your formal methods, reality is that the ocasional error
> like this will slip throuhg the net. The actual example is maybe a bit
> too crude, but it's easy enough to make it more subtle, without really
> adding anything to the discussion.

We need an example, because without it, I can't see why this team is
going to change sign.  The mistake will be found at the very first unit
test and fixed before anyone else even notices (lucky programmer!).

You are trying to have it both ways.  To ensure you can reasonably
change 'sign' you need it to be called in only one place, but that also
means there are trivial tests that will spot any error before the call.

> So my method is to say "are we running a video game or a life support
> system?".  If the answer is a video game, then I would write sign(NaN)
> to return 0.  Plough on and hope that the error is masked. If the
> answer is a life support system, I would say "set off the alarm at
> this point".

What process in the programming team causes this to occur?

Did the test coverage tool discover an untested path in the function?
If so, since it's called in only one place, all eyes can be on that call
to see if there's a problem.  (And of course, the missing assert will
also be spotted at that point.)

-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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