Re: (part 33) Han from China answers your C questions
- From: Richard Heathfield <rjh@xxxxxxxxxxxxxxx>
- Date: Fri, 21 Nov 2008 18:10:09 +0000
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.
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. 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>
Few are the people who check for strncpy() NUL termination, and even
fewer are the people who handle strncpy() truncation.
I simply don't use strncpy() as I regard it as broken
I rarely use it. It's actually rather good at doing the job it was designed
to do (but it's a job that doesn't seem to come up very often). What it
wasn't designed to do was "be a safe strcpy", as so many people seem to
think.
The same goes for
snprintf(), fgets(),
I check fgets() for truncation. I may choose to simply
report "over-length line" but I don't ignore it.
I don't actually use fgets very often. When I do, it's because I have
control over the input. If I don't have that control, I'll use something
hand-rolled instead.
and friends (for truncation). There is a certain
level of anal checking that few coders seem willing to tolerate for
long.
and it usually bites if you don't do the checking
Right.
How often does one see the following code:
if(fclose(f) == EOF) { ... }
Exactly.
hardly ever
True enough. Most people aren't taught that it matters. This is purely a
matter of teaching people how to use fclose properly.
A program that crashes tells me nothing sufficiently useful to help me
fix the problem. "It's screwed" is insufficiently useful, except
insofar as it persuades me to ditch the program and try something
better.
at least I *know* it has bug. A stack trace and/or examination
of an activity log might enable me to debug it.
Yeah, if I have the source, or if I'm a whizz at machine code and don't
have to worry about IPR violations. But if I have the source, I can
provide myself with far more useful information than "oh, it's crashed".
And most people don't have the source code. When was the last time you
debugged Internet Explorer after it crashed on you? Or Word? Or Acrobat?
Hmm? For the vast majority of people, the word "never" is highly
appropriate at this point.
A program that silently but predictably produces incorrect results can
be studied and fixed.
yuk!
http://en.wikipedia.org/wiki/Therac-25
A radiotherapy device that goes awry is going to hurt people, okay? So -
how many people does it have to kill before I do something about it? Let's
be cruelly cynical and say six. Okay, so six people are going to die, no
matter what. If they die predictably (and yes, I KNOW it's better for
people not to die, okay?), it's going to be reasonably easy to find and
fix the problem - or to decide it can't be fixed and scrap the product.
But if the behaviour of the machine becomes unpredictable, then the
machine might silently harm dozens or even hundreds of people - without
realising it - before I get my quota of six (or whatever) deaths that
prompt my investigation. Unpredictability is no virtue in any machine,
with the possible exceptions of games of chance and chaos-theory-related
programs. If I know how it will behave in any given situation, it makes
the problems easier to fix or at least identify.
Best of all is a program that, having determined that something is
wrong, produces noisy error messages, and then fails gracefully
(perhaps halting, but certainly not crashing).
yes!
Quite so.
I believe my critic would agree with you.
Anyone who thinks a crashing program is a good program doesn't belong
in the industry.
I think people have been a bit loose in their use of
the term "crash". If it stack dumps it's a crash but
abort() and assert() may both generate stack dumps.
Assertions have their place - in development. As for abort(), it may or may
not be appropriate as an absolute last-ditch measure. If fly-by-wire
software on a fighter aircraft is clever enough to realise it's totally
lost the plot, I hope for the pilot's sake that it stays up and running
long enough for the ejection procedure to work. Just aborting simply isn't
good enough.
<snip HfC nonsense>
--
Nick Keighley
one of the reasons for the longevity of the Roman bridges is that
their designers had to stand under them when they were first used.
It may be time to put a similar discipline into the software field.
Couldn't agree more.
.. it is absurd to make elaborate security checks on
debugging runs, when no trust is put in the results, and
then remove them in production runs, when an erroneous
result could be expensive or disastrous.
C. A. R. Hoare
I think that's a strange way to look at it. When you're constructing a
building (as I'm sure practically everybody reading this article *is*),
you put scaffolding up. But when the building is finished, it's time to
take the scaffolding away. If the scaffolding cannot safely be removed,
the building is not ready for use.
Likewise, assertions are there to catch incorrect assumptions in the code.
Sometimes, these can be quite lengthy. For example, I have some tree code
which checks, via an assertion-like mechanism, the structural integrity of
a tree - right number of members, all reachable, all in the correct
relation to one another - after every addition, every deletion, every
lookup, and every walk. This is clearly an O(m*n) operation, where m is
the number of adds, deletes, lookups, and walks, and n is the number of
items in the tree. It's expensive. If I left it in the production code,
the live code would run like a dog with one leg. It's in the development
code as a development tool, not as a production tool. It would be absurd
to leave it in place in production code, but I'd feel moderately unhappy
about switching it off during development.
--
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
.
- Follow-Ups:
- Re: (part 33) Han from China answers your C questions
- From: Flash Gordon
- Re: (part 33) Han from China answers your C questions
- References:
- (part 33) Han from China answers your C questions
- From: George Orwell
- Re: (part 33) Han from China answers your C questions
- From: Nick Keighley
- (part 33) Han from China answers your C questions
- Prev by Date: Re: The meaning of #line
- Next by Date: Re: (part 21) Han from China answers your C questions
- Previous by thread: Re: (part 33) Han from China answers your C questions
- Next by thread: Re: (part 33) Han from China answers your C questions
- Index(es):
Relevant Pages
|
