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

Flash Gordon said:

<snip>

even proving that the result is a prime won't prove that it is the
correct output.

Okay, fair point. So how are you going to test it? You *were* going to test
it, right? And how would crashing solve your problem here?

<snip>

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.

Yes.

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.

Incorrect results typically give you more information about what went wrong
than no results whatsoever. If your output is:

"MANCHESTER UNITED 0, LEEDS UNITE"

you've already got a pretty good idea of what went wrong, right there. Or
if it's "MANCHESTER UNITED 0, LEEDS UNITED -2147483648, that's a pretty
big clue, too. But if it's, then you have to start guessing.


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.

I would rather debug starting from as much relevant information about the
error as possible - including, but not limited to, its ostensible
locality.

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

Same here.

Then what are we arguing about? :-)

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

Quotes noted with wry smile. Been there, done that, got the impossible
tee-shirt.

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.

Yes, "repeatable" being the important word here. I've found that keeping
the behaviour well-defined is a great aid to repeatability, and
well-defined behaviour means no crash - QED! :-)

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.

Yes, but only the relevant data! The data that you know to look at, because
it's within the domain of the program's activity. With undefined
behaviour, you have to check Keith Thompson's hard disk, in case your
program running on your machine messed it up. Okay, so that's a caricature
- but the underlying point is genuine.

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.

Sure, but my point is that IF the behaviour is well-defined, you only have
to look in the relevant places. If the behaviour is undefined, you have to
look in what would otherwise be irrelevant places - or trust that the
undefined behaviour *didn't* screw your system in some arbitrarily subtle
way.

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,

Right. So would I.

on
one application I've been working on that handling can mean aborting the
program with a suitable error message.

I don't consider dev-time assertions to be crashes.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
.

Relevant Pages

  • 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 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
    ... 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 ... But I'd rather debug incorrect results any day. ... undefined behaviour to crash. ...
    (comp.lang.c)
  • Re: Screensaver Issues - Kernel32.DLL Error
    ... until you face the crash itself... ... the screensaver NEVER crashes if run from command-line (be it ... > Do you really think I didn`t debug the hell out of my code? ...
    (microsoft.public.win32.programmer.directx.graphics)
  • Re: dialog.domodal causes crash
    ... Debug build is OK, Release build crashes and displays the MS "MFC ... I've put MessageBox'es at different points to identify where the crash ... The MessageBox ...
    (microsoft.public.vc.language)