On 12/09/2023 00:40, Malcolm McLean wrote:
> On Monday, 11 September 2023 at 23:19:07 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Monday, 11 September 2023 at 16:26:30 UTC+1, Ben Bacarisse wrote:
>>>>
>>>> Someone brought up the analogy with a safety belt, but it's no a good
>>>> one. Covering cases that "can't happen" (it used to be called defensive
>>>> programming in another bad analogy with defensive driving) is nothing
>>>> like a safety belt. All it usually does is push the error somewhere
>>>> else, since if the input was "unexpected" the contrived result will be
>>>> too.
>>>>
>>> That analogy was because David Brown was making out that, because I
>>> consider the possibility that there might be errors in my code, I'm
>>> therefore a bad programmer.
>> That seems very unlikely. Do you have a citation?
>>> You're right that when a program is incorrect, it's hard to provide correct
>>> behaviour. But things which are liley to be helpful and things which are
>>> likely not to be. Bascially programs fall into two categories.
>> Oh, here we go...
>>> Life support
>>> systems, where the worst thing you can do is return wrong results. And
>>> video games, where the worst thing you can do is return no results.
>> I am sure you can shoe-horn any other possibility into what you imagine
>> these two categories contain.
>>
>> I will, however note that one is often designing code not programs. The
>> authors of the C library don't know where it will be linked.
>>> If the life support system returns the wrong value for the oxygen, then
>>> the patient suffocates to death. If it crashes out, the alarm goes off, the
>>> nurse comes running, and the patient is administered emergency manual
>>> oxygen whilst a new machine is brought.
>> Is it "crashing out" because a result was wrong or because there was no
>> result? I'm just curious where this case lies in your arbitrary divide.
>>
> Crashing out means no results. The oxygen pipe has some sort of regulator
> attached to it which receives instructions from our program on how
> much oxygen to administer to the patient. If the program has an error,
> then bascially it can malfunction in one of two ways. It can send a wrong
> result to the regulator instructing it to administer the wrong amount
> of oxygen to the patient. Or it can send no instructions to the regulator
> at all.
>
> Now obviously if the program is incorrect, there's no way of guaranteeing
> correct behaviour. But, at risk of flogging the example to death, let's say
> that the root of the problem is that a NaN is generated, fed to a sign()
> function, then used to determine whether to increase or decrease the flow.
>
> Now we've got several strategies. One is to say "if sign() is called with a
> NaN that must indicate a programming error. Therefore terminate the program."
> Another is to say "the sign of NaN is NaN, return NaN". Another is to say
> "if we return zero the calling function will likely do the right thing. Certainly
> more likely than if we return 1 or -1, and those are our three options."
>
> So with strategy one, we get no results. With strategy two we shunt the
> decision elsewhere. With strategy three we get what are likely to be wrong
> results.
>
> Now, as I said, if it's a life support system in an environment like a hospital, you
> definitely want strategy one. The program crashing is no different to the processor
> ceasing to work because its electrical supply has failed. Any hospital worth
> it's salt will have procedires in place to deal with that possibility. If the machine
> just quietly dispeneses a supply of oxygen which is too low, but within normal
> clinical bounds, the patient is much more likely to die before anyone realises that
> anything is wrong.
>
> And if sign() is a library function, then you need two versions of the library.
> The life support machine version, and the video games version.
>

All I can say is that I am glad you write video games for a living, and
not the software for life support systems.

Perhaps this should be the end of this thread?

On 12/09/2023 11:49, David Brown wrote:
> On 11/09/2023 19:08, Malcolm McLean wrote:

>> But things which are liley to be helpful and things which are
>> likely not to be. Bascially programs fall into two categories. Life
>> support
>> systems, where the worst thing you can do is return wrong results. And
>> video games, where the worst thing you can do is return no results.
>
> You're mad.  Or you are trolling.
>
> It's a spectrum - obviously.

It's more of a gamut.

> Mistakes do happen.  Hiding them is a bad idea.  Examples of that would
> include a language/compiler having a default "return 0;" on non-void
> functions, explicitly adding a "return 0;" when code flow should never
> reach that point, or having a function that should never be given a NaN
> have handling for NaNs.

And yet, such default initialisations do exist in C, and they could well
hide certain kinds of errors.

For example, static objects are set to all zeros unless explicitly
initialised. That is generally considered useful, and has come to be
something you can confidently rely on.

>  An "unreachable();" statement is clearer and
> avoids misconceptions, as well as giving more efficient code in some
> cases, and potentially allowing more static error checking.  It should
> be possible to turn it into a trap of some sort (abort, run-time error
> message, debugger breakpoint, etc.) via either compiler options or
> changing the definition of a macro or the function - this is something
> you cannot do with a "return 0;" or "return x;" statement.

I might use 'return 0' in my language to satisfy a constraint. But I
might sometimes return an error code, such as -1, 9999, or i64.min, just
in case control does reach that point. I might after all make a
modification that could make that possible.

Alternately, I can add a call to an error function, one that is defined
to have a suitable return type to satisfy the constraint (so no separate
return is needed).

On PCs, such things have insignificant overheads. I can understand that
on your targets, they could be significant.

But what you are arguing for is to use such leaner, less foolproof
mechanisms even on systems where there are plenty of resources.
Ironically, ones which require compilers that need plenty of their own
resources to use effectively.

On Tuesday, 12 September 2023 at 12:52:24 UTC+1, Bart wrote:
> On 12/09/2023 11:49, David Brown wrote:
> > On 11/09/2023 19:08, Malcolm McLean wrote:
>
> >> But things which are liley to be helpful and things which are
> >> likely not to be. Bascially programs fall into two categories. Life
> >> support
> >> systems, where the worst thing you can do is return wrong results. And
> >> video games, where the worst thing you can do is return no results.
> >
> > You're mad. Or you are trolling.
> >
> > It's a spectrum - obviously.
> It's more of a gamut.
>
If a program has an error in it, then it cannot return correct results.
It can return wrong results. Or it can return no results at all.

Now every user must have a preference. Would you prefer wrong results,
or no results? Some stupid users would say "neither" but of course that's
not an option. It's a given that the program is incorrect. I suppose they could
say "both are exactly equal", but that's very unlikely. There must be an ordering.
If the user is a life support system, you definitely want no results rather than
wrong results, because you can detect no results easily, whilst wrong results
might slip through. If the user is a video games player, you definitely want wrong
results rather than no results. If the game terminates with an error message it
is dead and enjoyment is ruined. If some of the results are wrong, most likely
it will be only a glitch and it will recover, and the user can continue playing.

Now of course other programs can be less extreme. No-one is going to die if a
scientific spreadsheet returns wrong results for a statistical analysis. But errors
will creep into the published paper. Clearly you want no results. A wordprocessor,
bugs are far more annoying than in a video game. But the user can usually see
any errors immediately. So you want to display wrong results rather than have
no results.
Every user must be in one of those two classes. Either no results are better than
wrong results, or wrong results are better than no results.

On 12/09/2023 13:52, Bart wrote:
> On 12/09/2023 11:49, David Brown wrote:
>> On 11/09/2023 19:08, Malcolm McLean wrote:
>
>>> But things which are liley to be helpful and things which are
>>> likely not to be. Bascially programs fall into two categories. Life
>>> support
>>> systems, where the worst thing you can do is return wrong results. And
>>> video games, where the worst thing you can do is return no results.
>>
>> You're mad.  Or you are trolling.
>>
>> It's a spectrum - obviously.
>
> It's more of a gamut.

Fair enough - it is not one-dimensional. But it is certainly not binary!

>
>> Mistakes do happen.  Hiding them is a bad idea.  Examples of that
>> would include a language/compiler having a default "return 0;" on
>> non-void functions, explicitly adding a "return 0;" when code flow
>> should never reach that point, or having a function that should never
>> be given a NaN have handling for NaNs.
>
> And yet, such default initialisations do exist in C, and they could well
> hide certain kinds of errors.

Yes, there are always tradeoffs here. The efficiency benefits of
initialising data to 0 can be significant, so it is worth doing for
static data at startup, and it is often useful for dynamic memory
allocation. (It is also useful in some environments to prevent the risk
of leaking data from one process to another.) It would have been
reasonable for C to insist that every statically allocated variable had
an explicit initialiser, but I think it is clear enough that you get 0
by default and other initialisations override that. It would, perhaps,
have been better if using uninitialised statically allocated data could
be detected at compile time and an error message given, but I can't see
how that would be feasible.

For local non-static variables, on the other hand, it is a much more
realistic task to detect when they are used without initialisation, so
it is a good thing that there is no default initialisation here.

(Sometimes it would be convenient to have a standardised syntax for
saying that a variable should be left uninitialised. In my line of
work, that would make sense for buffers and the like - there is no
advantage in clearing them at startup.)

>
> For example, static objects are set to all zeros unless explicitly
> initialised. That is generally considered useful, and has come to be
> something you can confidently rely on.

It has, AFAIK, /always/ been something you can confidently rely on
except for one or two terrible C implementations. (The biggest sinner
here is Texas Instrument's C implementations, many of which do not
zero-initialise uninitialised static data. It is really a PITA.)

>
>>   An "unreachable();" statement is clearer and avoids misconceptions,
>> as well as giving more efficient code in some cases, and potentially
>> allowing more static error checking.  It should be possible to turn it
>> into a trap of some sort (abort, run-time error message, debugger
>> breakpoint, etc.) via either compiler options or changing the
>> definition of a macro or the function - this is something you cannot
>> do with a "return 0;" or "return x;" statement.
>
> I might use 'return 0' in my language to satisfy a constraint. But I
> might sometimes return an error code, such as -1, 9999, or i64.min, just
> in case control does reach that point. I might after all make a
> modification that could make that possible.
>
> Alternately, I can add a call to an error function, one that is defined
> to have a suitable return type to satisfy the constraint (so no separate
> return is needed).
>
> On PCs, such things have insignificant overheads. I can understand that
> on your targets, they could be significant.

/Sometimes/ on PC's they have insignificant overhead - certainly more
often than in embedded systems. But sometimes on PC's they have
significant overheads too.

Consider the infamous sign function :

int sign(double x) {
if (x < 0.0) return -1;
if (x == 0.0) return 0;
if (x > 0.0) return 1;
unreachable();
}

When "unreachable()" has no effect (other than informing the compiler
and the reader that control flow never reaches this point), the function
is a "pure" function. The output depends solely on the input. (This is
also true if it were replaced by "return 0;" or "return x;".) Such
functions are /much/ nicer to handle for optimisation and analysis, both
by humans and software. A compiler that knows a function is "pure"
(such as by using gcc or C23 attributes, or simply because the
definition is available - probably as an inline function) can move the
call around, in and out of loops, or eliminate or pre-calculate calls.
A human trying to understand the code knows it is "safe" and cannot
affect other parts of the program.

However, if "unreachable()" can print an error message or halt the
program, it is a completely different situation. Now the function has
very significant observable behaviour, and cannot be optimised or
analysed in the same way. You have a totally different call graph for
the function, totally different stack usage analysis (that's important
in small embedded systems), different effects on things like stderr or
stdout streams, and so on. And that is all to handle a situation that
will never occur (at least, not once the calling code is debugged).

And you've got a line in your code that has major and potentially
catastrophic effects if it is run, but is completely untestable().

To me, these are very significant overheads. But to be clear - these
are overheads if the last line is an "abort()" or run-time error
handler. The overheads of a "return 0;" or the like are much smaller.
The caller still gets the wrong return value - but it can't expect
anything better when it gave an invalid argument.

I prefer a macro-based approach, or compiler flag option (or whatever
the equivalent solutions are in your language) that lets the user write
"unreachable();" for efficiency, while being able to easily make a
temporary halt or error message when fault-finding and debugging.

>
> But what you are arguing for is to use such leaner, less foolproof
> mechanisms even on systems where there are plenty of resources.

I am actually arguing that these are /better/ - not just leaner, but
give more possibilities for finding and fixing problems.

> Ironically, ones which require compilers that need plenty of their own
> resources to use effectively.

The PC I use for compiling code has a million times more ram than than
the target device for a program I am working on at the moment. I don't
mind that the compiler uses lots of resources if it saves resources on
the target.

Bart <bc@freeuk.com> writes:

> On 12/09/2023 02:39, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> (I don't have signbit to try it.)
>> I thought you had a C implementation?
>>
>
> I didn't realise it was in math.h, I thought it was POSIX.
>
> I don't have it, and the implementation is not trivial as it needs to work
> generically.

You do have it. You have posted results from more than one reasonably
full C implementation in the past.

> But using other compilers, I get these results:
>
> x sign(x) signbit(x)
> -5.0 -1 1
> -0.0 0 1
> 0.0 0 0
> 3.0 1 0
> nan 0 1
>
> (sign(nan) depends on how sign() is written.

You are tabulating a function without ether specifying or showing it.
Is that useful?

> My test nans always to be
> negative, but gcc shows them as 'nan', and tcc as '-1.#IND'.
>
> The same sign(nan) in my bcc gives -1, as I use ordered comparisons rather
> than unordered.

I don't know what that means, but does it matter? You can write sign(x)
to do anything you want it to do. There is (even in this thread) no
full specification for what it should do.

> My point was that signbit() and sign() do different things.

We agree!

--
Ben.

On 12/09/2023 14:49, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 12/09/2023 02:39, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> (I don't have signbit to try it.)
>>> I thought you had a C implementation?
>>>
>>
>> I didn't realise it was in math.h, I thought it was POSIX.
>>
>> I don't have it, and the implementation is not trivial as it needs to work
>> generically.
>
> You do have it. You have posted results from more than one reasonably
> full C implementation in the past.

I can't see it within bcc's math.h header.

Other implementations tend to have it as a macro that relies on libray
routines. But the library I use, msvcrt.dll, doesn't export those. And
I'm reluctant to implement such library code.

(I already have a small, internal support library; I'm planning to
remove that and move to inline code.)

If you mean within the other C compilers I have, then yes, that's what I
just posted about. Maybe you mean I'd previously posted code using
signbit, then I'd forgotten!

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

> On Tuesday, 12 September 2023 at 03:59:02 UTC+1, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>>
>> > On 11/09/2023 23:18, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> >>
>> >>> On Monday, 11 September 2023 at 16:26:30 UTC+1, Ben Bacarisse wrote:
>> >>>>
>> >>>> Someone brought up the analogy with a safety belt, but it's no a good
>> >>>> one. Covering cases that "can't happen" (it used to be called defensive
>> >>>> programming in another bad analogy with defensive driving) is nothing
>> >>>> like a safety belt. All it usually does is push the error somewhere
>> >>>> else, since if the input was "unexpected" the contrived result will be
>> >>>> too.
>> >>>>
>> >>> That analogy was because David Brown was making out that, because I
>> >>> consider the possibility that there might be errors in my code, I'm
>> >>> therefore a bad programmer.
>> >> That seems very unlikely. Do you have a citation?
>> >>
>> >>> You're right that when a program is incorrect, it's hard to provide correct
>> >>> behaviour. But things which are liley to be helpful and things which are
>> >>> likely not to be. Bascially programs fall into two categories.
>> >> Oh, here we go...
>> >>
>> >>> Life support
>> >>> systems, where the worst thing you can do is return wrong results. And
>> >>> video games, where the worst thing you can do is return no results.
>> >> I am sure you can shoe-horn any other possibility into what you imagine
>> >> these two categories contain.
>> >
>> > You also gave two extreme examples of applications.
>> I did not (I hope) suggest that there were only two types. Did I?
>>
> No. I did.

I know. I was replying to Bart who implied I did as well.

> If a program contains an error, it can behave in two ways.

What you really mean is that your point requires you to divide all the
possible behaviours into those two classes. Other people, in other
situations, might choose to divide the behaviours into correct or
incorrect. Or into within acceptable bound of accuracy, space and time
utilisation or outside those acceptable bounds. One picks the
classification for the point being made. I am not objecting to the
classification of behaviour, I am objecting to the notion that there is
only one.

> It can return wrong results, or it can return no results.

This bring up another problem relating to how we (you and I) view
programs. To me, a program containing an error (singular) can exhibit a
huge range of behaviour (as can, of course, a correct program). One
"error" (say omitting 'return E;' from the end of function) can result
in what you call wrong results on Wednesdays, correct results on Fridays
and no results when the year is divisible by four.

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.

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

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.

> Now for some programs, no results are better than wrong
> results, for other programs, wrong results are better than no
> results. There are N! possibilities. N is 2, so there are 2! or 2
> types of program.

This division can indeed be forced, but it's not a good one. A better
division is whether the program meets the spec or not. After all, that
is exactly what you are in effect calling for -- that all failures to
provide timely correct settings should be fatal errors.
>> > (But I've lost track of the discussion. To backtrack a little, I think it
>> > was the possibility of NaNs in floating-point values that would have caused
>> > an example non-void function to unexpectedly hit the closing '}'.)
>> I think so. But the discussion is devoid of all useful context. If the
>> numbers come, for example, from reading integer registers on hardware,
>> (and there is no maths library) provided we don't divide by zero you
>> won't get a floating point NaN. But maybe that's the kind of bug that
>> is being envisioned -- get two integers and divide without checking.
>>
> Thats one way you could generate a NaN.

They are not magic. In the situation I described, where the floating
point numbers come from non-zero divisions of integers, you won't get
one. Of course someone could come along later and set

double flow = 0.0/0.0;

but that's just a bug like any other (except maybe much easier to spot).
Setting

double flow = 1e-3;

rather than 1e+3 is also a bug and needs to be caught. 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.

>> But if that's the sort of programmer you have on the team, why worry
>> about sign() and NaN? They might write a function that falls off the
>> end because of a missing case in a switch or a forgotten break. The
>> NaNs will be the least of your worries in those cases.
>>
> 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.

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

>> So what is the development process? Who reviews code? Are function
>> contracts checked? How formally? Are test cases properly constructed
>> to give overall coverage? Are tests run with a run-time code sanitiser?
>> Can the team use Haskell instead?
>>
> 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.

--
Ben.

On 12/09/2023 16:17, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>

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

You can do a much simpler check in any language that doesn't need clever
analysis or knowledge of the special properties of NaNs.

Because the last return/last value is conditional, it can fail, but
there is no value associated with that failing path.

That can provided in various ways including an 'else' branch of an
if-else-if chain.

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. 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.
>
> 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.
The code might look like this.

double sensor_value = readsensors();
if (sensor_value == NaN) /* the bug */
handle_sensor_not_working();
else
{ double delta_oxgyen = sign(sensor_value) * step;
setoxygen(current_oxygen + delta_oxygen);
}

Now of course that should have been picked up in a code review. Somehow that
didn't happen and it slipped through.

So the specification is that if readsensors() return NaN, that means that the sensors
are not working, and we have recovery code to call that. But in fact it will not be called,
because the test has been miswritten.

>
> > Now for some programs, no results are better than wrong
> > results, for other programs, wrong results are better than no
> > results. There are N! possibilities. N is 2, so there are 2! or 2
> > types of program.
> This division can indeed be forced, but it's not a good one. A better
> division is whether the program meets the spec or not. After all, that
> is exactly what you are in effect calling for -- that all failures to
> provide timely correct settings should be fatal errors.
>
Yes. For the life support machine. But not for the video game.
>
> > Thats one way you could generate a NaN.
> They are not magic. In the situation I described, where the floating
> point numbers come from non-zero divisions of integers, you won't get
> one. Of course someone could come along later and set
>
> double flow = 0.0/0.0;
>
> but that's just a bug like any other (except maybe much easier to spot).
> Setting
>
> double flow = 1e-3;
>
> rather than 1e+3 is also a bug and needs to be caught. 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.
>
> > 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.
Similar errors do make their way into critical systems where the costs are
extremely high, like spacecraft, and there have been reports.
>
> 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.
>
> > 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.

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

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

Isn't that what Ben just wrote?

>>
>> 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.
>The code might look like this.

>double sensor_value = readsensors();

I sure hope not. There's no need to use floating point
in this case. The flow-rate is in units of O2 per unit time.

e.g milliliters per millisecond.

If you need higher resolution, microliters per microsecond.

In both cases, they're simple integers well within the
range of a 32-bit unsigned integer and there will never
be a NaN.

On Tuesday, 12 September 2023 at 17:48:52 UTC+1, Scott Lurndal wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >On Tuesday, 12 September 2023 at 16:17:18 UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
>
> >> 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.
> Isn't that what Ben just wrote?
> >>
> >> 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.
> >The code might look like this.
>
> >double sensor_value = readsensors();
> I sure hope not. There's no need to use floating point
> in this case. The flow-rate is in units of O2 per unit time.
>
> e.g milliliters per millisecond.
>
> If you need higher resolution, microliters per microsecond.
>
> In both cases, they're simple integers well within the
> range of a 32-bit unsigned integer and there will never
> be a NaN.
>
So what happens if the sensor doesn't give a reading?

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Tuesday, 12 September 2023 at 17:48:52 UTC+1, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> >On Tuesday, 12 September 2023 at 16:17:18 UTC+1, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> >>
>>
>> >> 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.
>> Isn't that what Ben just wrote?
>> >>
>> >> 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.
>> >The code might look like this.
>>
>> >double sensor_value = readsensors();
>> I sure hope not. There's no need to use floating point
>> in this case. The flow-rate is in units of O2 per unit time.
>>
>> e.g milliliters per millisecond.
>>
>> If you need higher resolution, microliters per microsecond.
>>
>> In both cases, they're simple integers well within the
>> range of a 32-bit unsigned integer and there will never
>> be a NaN.
>>
>So what happens if the sensor doesn't give a reading?

Whatever the design document for the O2 sensor requirements
specifies.

I would assume that the designer would anticipate such a
condition and the function that obtains the sensor reading
would indicate a failure condition that would be handled
according to the design specification. There is no need
to use a NaN for that, there are dozens of alternatives.

On 12/09/2023 18:28, Bart wrote:
> On 12/09/2023 16:17, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>
>>> 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.

To be fair, it will also give the same warning if you replace "Double"
with "Int". gcc will do the same - complain about a missing return,
even when the parameter is of type "int" and the guards /are/
exhaustive. (Note to Bart - you can try the Haskell code on
godbolt.org, just like gcc code. For both gcc and Haskell, you should
use -Wall for the warnings.)

>
> You can do a much simpler check in any language that doesn't need clever
> analysis or knowledge of the special properties of NaNs.
>
> Because the last return/last value is conditional, it can fail, but
> there is no value associated with that failing path.
>

That can certainly be a good first step, though you will get false
positives. A smart enough compiler (and neither gcc, clang, not the
Glasgow Haskell Compiler are smart enough) could do better if it saw the
conditionals actually covered all possibilities, such as a final "if
(isnan(x)) return 2;" line.

> That can provided in various ways including an 'else' branch of an
> if-else-if chain.
>
>

On 12/09/2023 20:07, Scott Lurndal wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On Tuesday, 12 September 2023 at 17:48:52 UTC+1, Scott Lurndal wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>> On Tuesday, 12 September 2023 at 16:17:18 UTC+1, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>
>>>>> 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.
>>> Isn't that what Ben just wrote?
>>>>>
>>>>> 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.
>>>> The code might look like this.
>>>
>>>> double sensor_value = readsensors();
>>> I sure hope not. There's no need to use floating point
>>> in this case. The flow-rate is in units of O2 per unit time.
>>>
>>> e.g milliliters per millisecond.
>>>
>>> If you need higher resolution, microliters per microsecond.
>>>
>>> In both cases, they're simple integers well within the
>>> range of a 32-bit unsigned integer and there will never
>>> be a NaN.
>>>
>> So what happens if the sensor doesn't give a reading?
>
> Whatever the design document for the O2 sensor requirements
> specifies.
>
> I would assume that the designer would anticipate such a
> condition and the function that obtains the sensor reading
> would indicate a failure condition that would be handled
> according to the design specification. There is no need
> to use a NaN for that, there are dozens of alternatives.

A common standard for sensors is to provide a 4 to 20 mA output for the
signal. That leaves 0 mA to indicate disconnected, and a value of
perhaps 1 mA to indicate a fault. That is, of course, at electrical
interface, but the same principles can be used in software, such as a
value of 0 to 1000 for valid readings and -1 for invalid readings.

And as you say, there are /many/ ways to do this. In C++, I might have
the readsensors() function return a std::optional<oxygen_ml_per_sec_t>
to make it easy to see when there is a valid value. In C, it would
perhaps be a struct with a bool "valid" flag. It's also common to have
such functions take a pointer-to-result parameter and return a status flag.

But I would not be returning either a double or an integer type - it
would be a specific type, whose name included the units, to make it as
difficult as possible to make a mistake.

David Brown <david.brown@hesbynett.no> writes:

> On 12/09/2023 18:28, Bart wrote:
>> On 12/09/2023 16:17, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>
>>>> 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.
>
> To be fair, it will also give the same warning if you replace "Double" with
> "Int".

Well that's disappointing. I thought it was doing a more interesting
analysis that would exclude such false positives. I must never have
written a set of guards that was not obviously exhaustive.

You do of course get a run-time error if you call sign with a NaN.

--
Ben.

On 13/09/2023 04:01, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 12/09/2023 18:28, Bart wrote:
>>> On 12/09/2023 16:17, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>
>>>>> 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.
>>
>> To be fair, it will also give the same warning if you replace "Double" with
>> "Int".
>
> Well that's disappointing. I thought it was doing a more interesting
> analysis that would exclude such false positives. I must never have
> written a set of guards that was not obviously exhaustive.
>
> You do of course get a run-time error if you call sign with a NaN.
>

You get that in gcc C too, if you use "-fsanitize=undefined". I guess
Haskell has somewhat equivalent behaviour as standard (like Ada).

Interestingly, if you change the C code to "int", the compiler still
warns about "control reaches end of non-void function". However,
"-fsanitize=undefined" does not result in extra code - the optimiser is
smart enough to see that the invalid return is never reached.

I feel a gcc "scope for improvement" bug report coming on...

On 13/09/2023 09:38, David Brown wrote:
> On 13/09/2023 04:01, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 12/09/2023 18:28, Bart wrote:
>>>> On 12/09/2023 16:17, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>
>>>>
>>>>>> 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.
>>>
>>> To be fair, it will also give the same warning if you replace
>>> "Double" with
>>> "Int".
>>
>> Well that's disappointing.  I thought it was doing a more interesting
>> analysis that would exclude such false positives.  I must never have
>> written a set of guards that was not obviously exhaustive.
>>
>> You do of course get a run-time error if you call sign with a NaN.
>>
>
> You get that in gcc C too, if you use "-fsanitize=undefined".  I guess
> Haskell has somewhat equivalent behaviour as standard (like Ada).

Sorry - you don't get the run-time check for gcc C, only for gcc C++,
since missing returns are not undefined behaviour in C. (They're
usually a bad idea, but not undefined behaviour in C. They are UB in
C++.) I hadn't noticed that I had a "-x c++" flag in my godbolt.org window.

>
> Interestingly, if you change the C code to "int", the compiler still
> warns about "control reaches end of non-void function".  However,
> "-fsanitize=undefined" does not result in extra code - the optimiser is
> smart enough to see that the invalid return is never reached.
>
> I feel a gcc "scope for improvement" bug report coming on...
>
>

On 13/09/2023 11:07, Malcolm McLean wrote:
> On Tuesday, 12 September 2023 at 20:23:32 UTC+1, David Brown wrote:
>> On 12/09/2023 20:07, Scott Lurndal wrote:
>>
>>> I would assume that the designer would anticipate such a
>>> condition and the function that obtains the sensor reading
>>> would indicate a failure condition that would be handled
>>> according to the design specification. There is no need
>>> to use a NaN for that, there are dozens of alternatives.
>> A common standard for sensors is to provide a 4 to 20 mA output for the
>> signal. That leaves 0 mA to indicate disconnected, and a value of
>> perhaps 1 mA to indicate a fault. That is, of course, at electrical
>> interface, but the same principles can be used in software, such as a
>> value of 0 to 1000 for valid readings and -1 for invalid readings.
>>
> I don't do embedded programming (I have dabbled, but nothing serious).
> But in most software engineering contexts, you would want to abstract
> away the result of a call to readsensors() from the physical details of
> how the sensors work.

Agreed. But the type of abstraction is going to be very variable
depending on the kind of code, and the part of the code you are working
on at the time. A double might be a reasonable choice for a sensor
value in simple cases where you know everything is fine - it would not
be a suitable type for tracking failures or possible uncertainties in a
measurement.

>>
>> And as you say, there are /many/ ways to do this. In C++, I might have
>> the readsensors() function return a std::optional<oxygen_ml_per_sec_t>
>> to make it easy to see when there is a valid value. In C, it would
>> perhaps be a struct with a bool "valid" flag. It's also common to have
>> such functions take a pointer-to-result parameter and return a status flag.
>>
>> But I would not be returning either a double or an integer type - it
>> would be a specific type, whose name included the units, to make it as
>> difficult as possible to make a mistake.
>>
> There's no way of attaching units to C variables, but one way is to use
> types.

You contradict yourself. There /is/ a way of attaching units to C
variables - you use types, as I said above.

You can also use good naming practices. Having a double called
"oxygen_ml_per_sec", rather than "oxygen_rate", attaches a unit to the
variable. The compiler can't check the units by name, but at least
human readers can do so.

> But in large programs that can cause problems because the types
> will usually only support the four rules of arithemetic.

You are jumbling concepts again, and imagining things. (Again, I would
encourage you to use Wikipedia whenever you want to use the word "the".
Look up "The Four Rules of Arithmetic" on Wikipedia - there is no such
thing. It's all in your mind, and it really does not help the
conversation at all.)

> So the usual solution
> is to use SI units. So a flow would be litres per second, not ml per second.
> (So you do need a decent range and prescision, because the values might
> very quite high or quite low in relation to the units).

Doubles in SI units can be a good choice in many cases, yes. But you
can do better in C - and if the code is safety-critical, such as this
case, you /should/ do better. Wrap the value in a struct, then the type
safety rules of C will stop you making mistakes. The types are more
awkward to use, of course - you have to use member access or specific
functions to access the actual values or do arithmetic on them. That is
a price worth paying for safety. (Alternatively, you use a language
that has better support for such things, like C++ or Ada.)

The bigger the program, the more important this kind of thing is - you
do not skimp on appropriate levels of safety just because the code base
is large.

On 13/09/2023 10:47, Malcolm McLean wrote:
> On Tuesday, 12 September 2023 at 19:07:54 UTC+1, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>> On Tuesday, 12 September 2023 at 17:48:52 UTC+1, Scott Lurndal wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>> On Tuesday, 12 September 2023 at 16:17:18 UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>
>>>>>> 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.
>>>> Isn't that what Ben just wrote?
>>>>>>
>>>>>> 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.
>>>>> The code might look like this.
>>>>
>>>>> double sensor_value = readsensors();
>>>> I sure hope not. There's no need to use floating point
>>>> in this case. The flow-rate is in units of O2 per unit time.
>>>>
>>>> e.g milliliters per millisecond.
>>>>
>>>> If you need higher resolution, microliters per microsecond.
>>>>
>>>> In both cases, they're simple integers well within the
>>>> range of a 32-bit unsigned integer and there will never
>>>> be a NaN.
>>>>
>>> So what happens if the sensor doesn't give a reading?
>> Whatever the design document for the O2 sensor requirements
>> specifies.
>>
> Most devices attached to microprocessors do put bits on the bus
> which represent fixed-point values. But this is a higher level function
> which is reading one or more sensors, and then combining the results
> into a single return value (you might have several sensors and it is
> taking an average). If the processor supports floating point, there's no
> particular reason not to use it, and to keep everything in the physical
> sensor's fixed point format which you read in at a low level.
>>
>> I would assume that the designer would anticipate such a
>> condition and the function that obtains the sensor reading
>> would indicate a failure condition that would be handled
>> according to the design specification. There is no need
>> to use a NaN for that, there are dozens of alternatives.
>>
> So an alternative would be
>
> /* return sensor reading in 16:16 fixed point format, INT_MAX for
> sensor fail */
> sint32_t readsensors();
>

typedef int32_t Q15_16_t;
static const Q15_16_t sensor_fail = (Q15_16_t) 0x80000000;

Q15_16_t x = read_sensors();
if (x == sensor_fail) {
...
} else {
...
}

"sint32_t" would be assumed to be an alias for "int32_t". If you mean a
fixed point format, the most common practice is the Q format.

> So what have we done? We got an informally specified NaN. INT_MAX
> is "not a number" in this context.

Yes, it is all explicit. It is not "informally" specified, unless
you've failed to make the specification clear. If it is there in the
code and documentation, it is "formally" specified.

>
> Another would be
> sint32_t readsensors(bool *hasdata);

Or, in the ordering used by virtually all C code in such cases,

bool read_sensors(sint32_t * sensor_value);

Or what is more common, and more useful, return a status code that is an
enumerated type indicating the success or type of error.

(I personally find it more intuitive to return a struct of status and
value, rather than have some return information by pointer parameter,
but that's just my own style.)

>
> Now hasdata indicates that the return is not a number when it is false. This
> is better as it isn't informlly specified and much less likely to be misunderstood.

I do agree that a boolean or other status indicator is often a better
choice, because you are less likely to get it wrong (even though it is
no more and no less "formally" or "informally" specified).

Alternatively, the return value can be within a struct, and then the
access functions would make it very difficult to use incorrectly.

> But all you are achieving is to move the NaN representation out of the return
> value and into a flag. You still have a not a number value, and there's still the
> risk that it will be used as a real value.

There is no way to make a system so foolproof that no fool can get it
wrong. But the suggestions here so far make it a /lot/ harder to get
wrong than using floating point NaN's.

>
> Which to be fair, there is still with a floating point NaN, as my bug indicated.
> However you have to be pretty unlucky (NaN is generated, treated as a number,
> then passed to a function which returns a number when passed NaN).
>
> I'm not saying that the inferface which says "return the sensor result as a real
> in natural (well, SI) units, and NaN if there is no data" is necessarily the very best
> that could be devised. But it's unexceptional.
>

And I am not saying it is not unusable as a choice - I am just saying it
is a bad choice compared to many alternatives, and not one I would ever
consider in my work. It's easy to get /so/ much better.

(I have worked on safety-critical systems, where failure, in extreme
cases, could result in death. Most of my work is not that critical,
however.)

On Wednesday, 13 September 2023 at 12:02:44 UTC+1, David Brown wrote:
> On 13/09/2023 10:47, Malcolm McLean wrote:
> > On Tuesday, 12 September 2023 at 19:07:54 UTC+1, Scott Lurndal wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>> On Tuesday, 12 September 2023 at 17:48:52 UTC+1, Scott Lurndal wrote:
> >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>> On Tuesday, 12 September 2023 at 16:17:18 UTC+1, Ben Bacarisse wrote:
> >>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>
> >>>>
> >>>>>> 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.
> >>>> Isn't that what Ben just wrote?
> >>>>>>
> >>>>>> 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.
> >>>>> The code might look like this.
> >>>>
> >>>>> double sensor_value = readsensors();
> >>>> I sure hope not. There's no need to use floating point
> >>>> in this case. The flow-rate is in units of O2 per unit time.
> >>>>
> >>>> e.g milliliters per millisecond.
> >>>>
> >>>> If you need higher resolution, microliters per microsecond.
> >>>>
> >>>> In both cases, they're simple integers well within the
> >>>> range of a 32-bit unsigned integer and there will never
> >>>> be a NaN.
> >>>>
> >>> So what happens if the sensor doesn't give a reading?
> >> Whatever the design document for the O2 sensor requirements
> >> specifies.
> >>
> > Most devices attached to microprocessors do put bits on the bus
> > which represent fixed-point values. But this is a higher level function
> > which is reading one or more sensors, and then combining the results
> > into a single return value (you might have several sensors and it is
> > taking an average). If the processor supports floating point, there's no
> > particular reason not to use it, and to keep everything in the physical
> > sensor's fixed point format which you read in at a low level.
> >>
> >> I would assume that the designer would anticipate such a
> >> condition and the function that obtains the sensor reading
> >> would indicate a failure condition that would be handled
> >> according to the design specification. There is no need
> >> to use a NaN for that, there are dozens of alternatives.
> >>
> > So an alternative would be
> >
> > /* return sensor reading in 16:16 fixed point format, INT_MAX for
> > sensor fail */
> > sint32_t readsensors();
> >
> typedef int32_t Q15_16_t;
> static const Q15_16_t sensor_fail = (Q15_16_t) 0x80000000;
>
> Q15_16_t x = read_sensors();
> if (x == sensor_fail) {
> ...
> } else {
> ...
> }
>
> "sint32_t" would be assumed to be an alias for "int32_t". If you mean a
> fixed point format, the most common practice is the Q format.
> > So what have we done? We got an informally specified NaN. INT_MAX
> > is "not a number" in this context.
> Yes, it is all explicit. It is not "informally" specified, unless
> you've failed to make the specification clear. If it is there in the
> code and documentation, it is "formally" specified.
>
Scott said "we have no NaNs". But what he meant was that we have no
NaNs as formally specified by IEEE. We still have representations which
indicate that a varibale doesn't hold a number. But because he hasn't called
them "not a number representations" in a formal way, they are "informally
specified".
If the sensor doesn't return a reading, you either have to represent that in
some way, which means that you need some sort of not a number representation,
or you have to make it impossible to read the sensor before checking that it
has a value. But the last is hard to achieve in C. (In C++ you can throw if the
sensor doesn't have a value, so code that operates on the missing value will
never be executed).
>
> > Now hasdata indicates that the return is not a number when it is false. This
> > is better as it isn't informlly specified and much less likely to be misunderstood.
> I do agree that a boolean or other status indicator is often a better
> choice, because you are less likely to get it wrong (even though it is
> no more and no less "formally" or "informally" specified).
>
INT_MAX is a value. So if you say "in this context, it is not a value" then that's legitimate,
but it's an informal specification in a way that "this boolean indicates an error condition"
is not.
>
> Alternatively, the return value can be within a struct, and then the
> access functions would make it very difficult to use incorrectly.
> > But all you are achieving is to move the NaN representation out of the return
> > value and into a flag. You still have a not a number value, and there's still the
> > risk that it will be used as a real value.
> There is no way to make a system so foolproof that no fool can get it
> wrong. But the suggestions here so far make it a /lot/ harder to get
> wrong than using floating point NaN's.
>
As Kaz explained, NaNs propagate. The intention is that we can do a complex series
of calculations, which may either have an error in it or have a mathematically
undefined value. Then if the final result is NaN, we know that the error has ocurred.
Now of course if the original NaN was generated as the result of a programmng error,
you can only try to mitigate the error in some way. The real solution is to correct
the code. But that can't be done at runtime and, with the best will in the world,
errors will slip through.
If you say "0x80000000 means sensor fail", and pass that through to a long series
of calculations, you might get lucky and trigger a hardware overflowe trap. But
more likely the hardware wont; trap on overflow and you will get a number out.
And it might even be in the range of legitimate values.

That's why NaNs were invented. They are not designed as nuisance to derail
programs. They're to indicate that a calculation has an error in it, and to enable
the program to detect that and take appropriate action.
>
> And I am not saying it is not unusable as a choice - I am just saying it
> is a bad choice compared to many alternatives, and not one I would ever
> consider in my work. It's easy to get /so/ much better.
>
No, its not easy to improve on the IEEE's system of non-signalling NaNs.
I am not saying the IEEE are gods and their system cannot be improved,
at all, or that it should be used in all cases. But it's not easy to get better
than "if there is no value, then the variable holds a NaN representation",
and then have a system so that all attempted operations on that value
also produce NaN, without any effort on the programmer's part.
>
> (I have worked on safety-critical systems, where failure, in extreme
> cases, could result in death. Most of my work is not that critical,
> however.)
>
It may be that you don't use floating point at all in such systems. But that
wouldn't be because IEEE has a system of NaNs. It would be because it's
too hard to get exact limits for accuracy with floating point.

On 13/09/2023 13:04, Malcolm McLean wrote:
> On Wednesday, 13 September 2023 at 11:43:34 UTC+1, David Brown wrote:
>> On 13/09/2023 11:07, Malcolm McLean wrote:
>>> On Tuesday, 12 September 2023 at 20:23:32 UTC+1, David Brown wrote:
>>>> On 12/09/2023 20:07, Scott Lurndal wrote:
>>>>
>>>>> I would assume that the designer would anticipate such a
>>>>> condition and the function that obtains the sensor reading
>>>>> would indicate a failure condition that would be handled
>>>>> according to the design specification. There is no need
>>>>> to use a NaN for that, there are dozens of alternatives.
>>>> A common standard for sensors is to provide a 4 to 20 mA output for the
>>>> signal. That leaves 0 mA to indicate disconnected, and a value of
>>>> perhaps 1 mA to indicate a fault. That is, of course, at electrical
>>>> interface, but the same principles can be used in software, such as a
>>>> value of 0 to 1000 for valid readings and -1 for invalid readings.
>>>>
>>> I don't do embedded programming (I have dabbled, but nothing serious).
>>> But in most software engineering contexts, you would want to abstract
>>> away the result of a call to readsensors() from the physical details of
>>> how the sensors work.
>> Agreed. But the type of abstraction is going to be very variable
>> depending on the kind of code, and the part of the code you are working
>> on at the time. A double might be a reasonable choice for a sensor
>> value in simple cases where you know everything is fine - it would not
>> be a suitable type for tracking failures or possible uncertainties in a
>> measurement.
>>>>
>>>> And as you say, there are /many/ ways to do this. In C++, I might have
>>>> the readsensors() function return a std::optional<oxygen_ml_per_sec_t>
>>>> to make it easy to see when there is a valid value. In C, it would
>>>> perhaps be a struct with a bool "valid" flag. It's also common to have
>>>> such functions take a pointer-to-result parameter and return a status flag.
>>>>
>>>> But I would not be returning either a double or an integer type - it
>>>> would be a specific type, whose name included the units, to make it as
>>>> difficult as possible to make a mistake.
>>>>
>>> There's no way of attaching units to C variables, but one way is to use
>>> types.
>> You contradict yourself. There /is/ a way of attaching units to C
>> variables - you use types, as I said above.
>>
>> You can also use good naming practices. Having a double called
>> "oxygen_ml_per_sec", rather than "oxygen_rate", attaches a unit to the
>> variable. The compiler can't check the units by name, but at least
>> human readers can do so.
>>> But in large programs that can cause problems because the types
>>> will usually only support the four rules of arithemetic.
>> You are jumbling concepts again, and imagining things. (Again, I would
>> encourage you to use Wikipedia whenever you want to use the word "the".
>> Look up "The Four Rules of Arithmetic" on Wikipedia - there is no such
>> thing. It's all in your mind, and it really does not help the
>> conversation at all.)
>>> So the usual solution
>>> is to use SI units. So a flow would be litres per second, not ml per second.
>>> (So you do need a decent range and prescision, because the values might
>>> very quite high or quite low in relation to the units).
>> Doubles in SI units can be a good choice in many cases, yes. But you
>> can do better in C - and if the code is safety-critical, such as this
>> case, you /should/ do better. Wrap the value in a struct, then the type
>> safety rules of C will stop you making mistakes. The types are more
>> awkward to use, of course - you have to use member access or specific
>> functions to access the actual values or do arithmetic on them. That is
>> a price worth paying for safety. (Alternatively, you use a language
>> that has better support for such things, like C++ or Ada.)
>>
>> The bigger the program, the more important this kind of thing is - you
>> do not skimp on appropriate levels of safety just because the code base
>> is large.
>>
> The techniques you are advocating will work only if the program is doing something
> relatively simple.
> They won't scale up to, for example, a statistical analysis of the oxygen flow.
> Because as you say "The types are more awkward to use, of course - you have
> to use member access or specific functions to access the actual values or do
> arithmetic on them.". All your carefully written and debugged statistical functions
> would have to be totally rewritten to accept the structures. Which for a life support
> system you could probably do, as money is literally no object, but not for something
> with cost constraints.

How you code things depends on the task at hand. For an oxygen
regulation system, safety is likely to be top priority - costs and
development time are far less important than confidence in the
correctness of the system. Other systems have different balances.

When you have an important control system like this, the most important
design decisions at the start are about how the system is split up and
modularised. Then you handle the appropriate tasks in the appropriate
place.

Thus it doesn't matter if the safe types used for oxygen regulation fit
badly with statistical analysis - you don't do statistical analysis on
the system that handles oxygen regulation.

You would have, for example, a dedicated microcontroller-based oxygen
regulator doing nothing but oxygen regulation. The desired flow rate
comes in on a simple interface (such as a serial link - no Ethernet,
USB, or other advanced connection), and information about current rates
go out on a similar link. Alarms are connected directly to lights,
sirens, and so on, as well as being passed on through the link. The
board here is independent, with its own battery backup. All the code is
written in carefully restricted subsets of C, C++ or Ada, according to
SIL standards, with all the paperwork, reviews, testing, and
documentation needed.

At the other end of the link is an embedded Linux system with
networking, a screen, a user interface, and so on - and whatever
statistical analysis you want. It is written in a combination of C,
C++, Python, R, PHP, Eiffel, Haskell, and whatever else suits. It's a
different world entirely.

The last thing you would want to do is reduce the quality or safety
controls on the regulator just so that you can "scale" it to fit with
some statistics package you found!

> C++ templates can come to the rescue here. But they come with their own safety
> problems. Because you don't know the range or precision of the types, it can be
> much harder to test a templated function.
>

C++ templates /do/ have their own testing challenges, yes. But C++ can
certainly make it a lot easier to write safe code for this kind of
thing. (It can also give you scope to write incomprehensible and
untestable code - safety-critical systems always use restricted subsets
of languages.) But you still keep the parts separate, even if you use
C++ on both parts.

Bart <bc@freeuk.com> writes:

> On 12/09/2023 16:17, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>
>>> 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.
>
> You can do a much simpler check in any language that doesn't need clever
> analysis or knowledge of the special properties of NaNs.
>
> Because the last return/last value is conditional, it can fail, but there
> is no value associated with that failing path.

But that is not always true. Multiple conditions can be exhaustive.
For example, Malcolm's sign:

double sign(double x)
{
if ( x < 0 ) return -1;
if ( x == 0 ) return 0;
if ( x > 0 ) return 1;
if (isnan(x)) return x;
}

> That can [be] provided in various ways including an 'else' branch of an
> if-else-if chain.

I think you are suggesting that a non-explicit "catch-all" should be
given to make the compiler's job easier. It maybe desirable from the
point of view of controlling diagnostics but the result is less clear so
I think it calls for a comment or even an assertion:

double sign(double x)
{
if (x < 0) return -1;
if (x == 0) return 0;
if (x > 0) return 1;
assert(isnan(x)); // all that's left...
return x;
}

--
Ben.

On 13/09/2023 13:45, Malcolm McLean wrote:
> On Wednesday, 13 September 2023 at 12:02:44 UTC+1, David Brown wrote:
>> On 13/09/2023 10:47, Malcolm McLean wrote:
>>> On Tuesday, 12 September 2023 at 19:07:54 UTC+1, Scott Lurndal wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>> On Tuesday, 12 September 2023 at 17:48:52 UTC+1, Scott Lurndal wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>> On Tuesday, 12 September 2023 at 16:17:18 UTC+1, Ben Bacarisse wrote:
>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>
>>>>>>
>>>>>>>> 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.
>>>>>> Isn't that what Ben just wrote?
>>>>>>>>
>>>>>>>> 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.
>>>>>>> The code might look like this.
>>>>>>
>>>>>>> double sensor_value = readsensors();
>>>>>> I sure hope not. There's no need to use floating point
>>>>>> in this case. The flow-rate is in units of O2 per unit time.
>>>>>>
>>>>>> e.g milliliters per millisecond.
>>>>>>
>>>>>> If you need higher resolution, microliters per microsecond.
>>>>>>
>>>>>> In both cases, they're simple integers well within the
>>>>>> range of a 32-bit unsigned integer and there will never
>>>>>> be a NaN.
>>>>>>
>>>>> So what happens if the sensor doesn't give a reading?
>>>> Whatever the design document for the O2 sensor requirements
>>>> specifies.
>>>>
>>> Most devices attached to microprocessors do put bits on the bus
>>> which represent fixed-point values. But this is a higher level function
>>> which is reading one or more sensors, and then combining the results
>>> into a single return value (you might have several sensors and it is
>>> taking an average). If the processor supports floating point, there's no
>>> particular reason not to use it, and to keep everything in the physical
>>> sensor's fixed point format which you read in at a low level.
>>>>
>>>> I would assume that the designer would anticipate such a
>>>> condition and the function that obtains the sensor reading
>>>> would indicate a failure condition that would be handled
>>>> according to the design specification. There is no need
>>>> to use a NaN for that, there are dozens of alternatives.
>>>>
>>> So an alternative would be
>>>
>>> /* return sensor reading in 16:16 fixed point format, INT_MAX for
>>> sensor fail */
>>> sint32_t readsensors();
>>>
>> typedef int32_t Q15_16_t;
>> static const Q15_16_t sensor_fail = (Q15_16_t) 0x80000000;
>>
>> Q15_16_t x = read_sensors();
>> if (x == sensor_fail) {
>> ...
>> } else {
>> ...
>> }
>>
>> "sint32_t" would be assumed to be an alias for "int32_t". If you mean a
>> fixed point format, the most common practice is the Q format.
>>> So what have we done? We got an informally specified NaN. INT_MAX
>>> is "not a number" in this context.
>> Yes, it is all explicit. It is not "informally" specified, unless
>> you've failed to make the specification clear. If it is there in the
>> code and documentation, it is "formally" specified.
>>
> Scott said "we have no NaNs". But what he meant was that we have no
> NaNs as formally specified by IEEE.

I took Scott's "NaNs never occur in my code" comment to mean that NaN's
- floating point NaNs, since that was the context - do not occur in the
code he writes. He wrote what he meant (AFAIK), and it was perfectly clear.

> We still have representations which
> indicate that a varibale doesn't hold a number. But because he hasn't called
> them "not a number representations" in a formal way, they are "informally
> specified".

The term "NaN" almost always refers to the values defined by IEEE for
its floating point formats. If that's not what you mean, say that.

This has /nothing/ to do with "formality". Something is "formal" is it
is well described and accurately specified and documented - otherwise it
is "informal". A function that documents a particular result to
indicate an invalid reading is "formal", while a function that assumes
it is obvious that invalid readings give a NaN would be "informal".

Discussions with you in this group are often very difficult, because you
inhabit a Humpty-Dumpty world where you think words mean exactly what
you intend them to mean - rather than what everyone else thinks they
mean. /Please/ learn to write in the same language the rest of us do,
and /please/ make it clear when you are "Malcolm-NaN's",
"Malcolm-formal", and any other private non-standard terms you want to use.

> If the sensor doesn't return a reading, you either have to represent that in
> some way, which means that you need some sort of not a number representation,
> or you have to make it impossible to read the sensor before checking that it
> has a value. But the last is hard to achieve in C. (In C++ you can throw if the
> sensor doesn't have a value, so code that operates on the missing value will
> never be executed).

Both are simple to do in C. Exceptions are nothing more than an
alternative way to return particular types of values that are convenient
and efficient for some kinds of coding.

>>
>>> Now hasdata indicates that the return is not a number when it is false. This
>>> is better as it isn't informlly specified and much less likely to be misunderstood.
>> I do agree that a boolean or other status indicator is often a better
>> choice, because you are less likely to get it wrong (even though it is
>> no more and no less "formally" or "informally" specified).
>>
> INT_MAX is a value. So if you say "in this context, it is not a value" then that's legitimate,
> but it's an informal specification in a way that "this boolean indicates an error condition"
> is not.

Nonsense. Please learn what "formal" and "informal" mean.

INT_MAX is a valid value for an "int". That does not mean it is a valid
value for a sensor reading.

>>
>> Alternatively, the return value can be within a struct, and then the
>> access functions would make it very difficult to use incorrectly.
>>> But all you are achieving is to move the NaN representation out of the return
>>> value and into a flag. You still have a not a number value, and there's still the
>>> risk that it will be used as a real value.
>> There is no way to make a system so foolproof that no fool can get it
>> wrong. But the suggestions here so far make it a /lot/ harder to get
>> wrong than using floating point NaN's.
>>
> As Kaz explained, NaNs propagate.

They do, in some circumstances. And that can be a convenient thing, in
some circumstances. (That's why they exist as a concept.)

> The intention is that we can do a complex series
> of calculations, which may either have an error in it or have a mathematically
> undefined value. Then if the final result is NaN, we know that the error has ocurred.
> Now of course if the original NaN was generated as the result of a programmng error,
> you can only try to mitigate the error in some way. The real solution is to correct
> the code. But that can't be done at runtime and, with the best will in the world,
> errors will slip through.
> If you say "0x80000000 means sensor fail", and pass that through to a long series
> of calculations, you might get lucky and trigger a hardware overflowe trap. But
> more likely the hardware wont; trap on overflow and you will get a number out.
> And it might even be in the range of legitimate values.

David Brown <david.brown@hesbynett.no> writes:
>On 13/09/2023 13:45, Malcolm McLean wrote:

>>> Yes, it is all explicit. It is not "informally" specified, unless
>>> you've failed to make the specification clear. If it is there in the
>>> code and documentation, it is "formally" specified.
>>>
>> Scott said "we have no NaNs". But what he meant was that we have no
>> NaNs as formally specified by IEEE.
>
>I took Scott's "NaNs never occur in my code" comment to mean that NaN's
>- floating point NaNs, since that was the context - do not occur in the
>code he writes. He wrote what he meant (AFAIK), and it was perfectly clear.

Indeed, NaN is a term of art referring specifically to the IEEE
floating point standard. I've never seen "NaN" used in any
other context (albeit some use it to refer to their grandmother :-).

<snip>

>Both are simple to do in C. Exceptions are nothing more than an
>alternative way to return particular types of values that are convenient
>and efficient for some kinds of coding.

Albeit an expensive and complex alternative way. One generally avoided
in real-time code.

On Wednesday, 13 September 2023 at 13:36:47 UTC+1, David Brown wrote:
> On 13/09/2023 13:45, Malcolm McLean wrote:
> > On Wednesday, 13 September 2023 at 12:02:44 UTC+1, David Brown wrote:
> >> On 13/09/2023 10:47, Malcolm McLean wrote:
> >>> On Tuesday, 12 September 2023 at 19:07:54 UTC+1, Scott Lurndal wrote:
> >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>> On Tuesday, 12 September 2023 at 17:48:52 UTC+1, Scott Lurndal wrote:
> >>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>> On Tuesday, 12 September 2023 at 16:17:18 UTC+1, Ben Bacarisse wrote:
> >>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>
> >>>>>>
> >>>>>> In both cases, they're simple integers well within the
> >>>>>> range of a 32-bit unsigned integer and there will never
> >>>>>> be a NaN.
> >>>>>>
> >>>>> So what happens if the sensor doesn't give a reading?
>>>>>>
> >>>> I would assume that the designer would anticipate such a
> >>>> condition and the function that obtains the sensor reading
> >>>> would indicate a failure condition that would be handled
> >>>> according to the design specification. There is no need
> >>>> to use a NaN for that, there are dozens of alternatives.
> >>>>
> >>> So an alternative would be
> >>>
> >>> /* return sensor reading in 16:16 fixed point format, INT_MAX for
> >>> sensor fail */
> >>>
> >>> So what have we done? We got an informally specified NaN. INT_MAX
> >>> is "not a number" in this context.
> >>
> > Scott said "we have no NaNs". But what he meant was that we have no
> > NaNs as formally specified by IEEE.
> I took Scott's "NaNs never occur in my code" comment to mean that NaN's
> - floating point NaNs, since that was the context - do not occur in the
> code he writes. He wrote what he meant (AFAIK), and it was perfectly clear.
>
Yes, it's perfectly clear wht he means. NaN is an IEEE representation which
means that a varaible doesn't hold a number. And he doesn't have any such
representations in his code. And you can do without them. But only by having
an alternative representation that mean s"this variable does not hold a number".

That's what wasn't taken on board and people are struggling with.

You achieve vety little by rejecting the accepted, formally specified, supported
representation of not a number, and substituting your own ad hoc representation.
> > If the sensor doesn't return a reading, you either have to represent that in
> > some way, which means that you need some sort of not a number representation,
> > or you have to make it impossible to read the sensor before checking that it
> > has a value. But the last is hard to achieve in C. (In C++ you can throw if the
> > sensor doesn't have a value, so code that operates on the missing value will
> > never be executed).
> Both are simple to do in C. Exceptions are nothing more than an
> alternative way to return particular types of values that are convenient
> and efficient for some kinds of coding.
>
No look. We have a C interface. In C, the only easy way to write the code to
read the sensors is something like this.

oxygen_flow_t oxygen;

oxygen = readsensors();
/* this code is always reached */
if (doesent_have_a_value(oxygen))
/* handle missing data here */

Of course you could return a bool to indicate the there is no data rather than have
something in oxygen_flow_t to mean the same thing, and there are various variations
on the same theme. But there's esentially only one way to do it. Control returns to the caller,
and "oxygen" is in scope. So if "oxygen" doesn't hold a number, we have to have a way
of representing that.
( I know that you can fiddle about with longjmp() or other ways of not returning to caller,
but they are difficult to implement and going against the language).

In C++ we can do this

oxygen_flow_t readsensors()
{ if (nodata())
throw myexception::sensorfailure;
return always_valid_value();
}

Now the code after the call is not executed unless the return value is valid. So we don't need
a way of representing that an oxygen_flow_t doesn't hold a number, because it always does.