Re: (part 33) Han from China answers your C questions

Richard Heathfield wrote, On 21/11/08 22:43:
Flash Gordon said:

Richard Heathfield wrote, On 21/11/08 18:10:
Nick Keighley said:

<snip>

Richard Heathfield seems to believe incorrect results are better
than a crash on the grounds that you can detect incorrect results.
Well I'm not so sure. If it were that easy to calculate the
correct results why are you bothering to run the program at
all?
If I as the programmer can't decide, for a given set of inputs, what the
outputs should be, I am in no position to write the program in the first
place.
There are very useful programs for which a programmer is not going to be
able to decide on what the correct output is prior to running the
program. A simple example is a program for calculating prime numbers
larger than a specified value. If the specified value is the largest
currently known prime number (which is a useful starting point) then the
programmer obviously does not know what the correct output is.

Sure. So you test it on known prime numbers. BIG known prime numbers. If it
can find a few million big known primes, I would trust it to produce a
hitherto unknown prime candidate for checking with known-good
primality-testing programs using different algorithms. (If you have those
other programs, why bother writing this one? Well, maybe it's a speed
thing - maybe it can discard pseudoprimes much quicker than other
programs, say.)

That is still not knowing the answer in advance. If you have an
additional requirement that it be the next highest prime number then
even proving that the result is a prime won't prove that it is the
correct output.

I don't want my program to produce incorrect results
and then merrily run on.
I don't want my program to produce incorrect results. But if it's going
to do that, I'd rather be able to find out why. And that task is
generally a lot easier if I know what the incorrect results *are*. If
the program just crashes, I am deprived of useful debugging information.
In my experience if the crash is at time t and the incorrect results (if
a crash is prevented) can be spotted at time t+delta (for some positive
delta) then you can can more information from the crash since it is
nearer the actual bug.

It's just a symptom, not a cause.

So are the incorrect results.

And it's merely a fact. "We got this far,
and it crashed." But you don't actually know why.

The same applies to incorrect results.

Yes, backtraces are very
useful. I'm not saying you *can't* debug a segfault. And it's not even
*that* difficult to do. But I'd rather debug incorrect results any day.

I would rather debug starting from as close to where the error is as
possible.

And I certainly wouldn't want my code to crash in production.

Same here. As a result on a legacy project I have slowly added in lots
of traps for "impossible" conditions.

I wish I
could claim that my code never does crash in production. Of course,
sometimes it does happen, but it's a circumstance that I would very much
prefer to avoid.

I try to avoid it as well. I'm also not arguing that crashes are a good
thing, although repeatable crashes can be easy to debug.

What's more, I am
left wondering what damage the program may have done in the way of
filesystem corruption, dropped packets, etc during its route from
undefined behaviour to crash.
<snip>

There is the same problem if you get incorrect results.

No, sir, there isn't - if the behaviour of your program is *well-defined*,
you know the limits of what it can do. If the behaviour of your program is
undefined, all bets are off. And a crash is basically one aspect of
undefined behaviour.

With a lot of SW the limits within well defined behaviour can include
completely trashing your data.

How do you know
it has not, for example, updated a million records in your database with
garbage values before the visibly incorrect result is seen?

If it's a well-defined program, I know it didn't do that because it's a
graphics filter, not a database program. But if the behaviour were
undefined, I couldn't be sure.

You introduced networking as a possibility, I introduced databases.

I'm not arguing in favour of undefined behaviour, just that a crash
closer to the point of error can be faster to debug than a detected
incorrect further away. Personally I would generally try and trap
conditions which would otherwise crash the program and handle them, on
one application I've been working on that handling can mean aborting the
program with a suitable error message.
--
Flash Gordon
If spamming me sent it to smap@xxxxxxxxxxxxxxxxx
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/
.

Relevant Pages

  • Re: (part 33) Han from China answers your C questions
    ... than a crash on the grounds that you can detect incorrect results. ... I don't want my program to produce incorrect results. ... If I left it in the production code, ...
    (comp.lang.c)
  • Re: (part 33) Han from China answers your C questions
    ... If it crashes I know for certain it has failed and can start ... concentrating on testing with the specific input that caused the crash ... The same applies to incorrect results. ... one aspect of undefined behaviour. ...
    (comp.lang.c)
  • Re: (part 33) Han from China answers your C questions
    ... I don't want my program to produce incorrect results. ... In my experience if the crash is at time t and the incorrect results (if ... undefined behaviour to crash. ...
    (comp.lang.c)
  • Re: (part 30) Han from China answers your C questions
    ... code that doesn't crash and doesn't work ... (i.e. silently produces incorrect results), ... when I said "crashes" I actually meant "aborts as soon as ... more graceful abort with a custom error message. ...
    (comp.lang.c)
  • Re: (part 33) Han from China answers your C questions
    ... positive delta) then you can can more information from the crash since ... The same applies to incorrect results. ... But I'd rather debug incorrect results any day. ... although repeatable crashes can be easy to debug. ...
    (comp.lang.c)