(part 33) Han from China answers your C questions

Richard Heathfield said:
Andrey Tarasevich said:



What "Han from China" apparently is trying to tell
you is that code that doesn't crash and doesn't work is better than code
that crashes.

What "Han from China" is trying to tell us can safely be ignored, since
"Han from China" has made little if any effort to persuade anyone that his
views are worth listening to - instead, he's gone straight for mockery.


Wow, talk about a blow to "the enemy of my enemy is my friend". When I
saw that *** Heathfield had jumped into this thread, my first thought
was that he was doing his usual gang-bang thing, jumping on top of
a man when he's down. Instead he comes in here and tears one of my critics
a new ***. I think *** secretly admires me. He sees in me the
rebellious spirit of his own dark side...

I actually would have a beer with Nick Keighley and double team a chick
with him. But he's been an ass when I've made errors, so I was simply
returning the favor.

So let's skip over them completely, and cut to the issue itself.

You present two possibilities: code that doesn't crash and doesn't work
(i.e. silently produces incorrect results), and code that crashes. You go
on to suggest...

In reality, the exact opposite is true: when your code's
internal invariants are irrecoverably violated, the best possible
outcome is the one when the code crashes as soon as possible, instead of
continuing to run.

If that belief is reflected in the programs you write, I would not want to
run any of them.


I believe the point my critic was making was that a program that crashes
has advantages over one that doesn't. He has made a rather subtle distinction
between code that crashes and code that is exploited, since the latter
continues to run. Continuing to run (whether as the result of an exploit
or the result of truncated garbage data) is in many ways more dangerous
than simply terminating as the result of a crash.

I don't disagree with Mr. Tarasevich that the code solution I suggested
sucks. It does suck. However, I would guess that the original code
and my code combined account for 98% of the C sockets code out there that
performs DNS name resolution. That's certainly no excuse, but ultimately,
I'm too lazy to change my ways.

Few are the people who check for strncpy() NUL termination, and even
fewer are the people who handle strncpy() truncation. The same goes for
snprintf(), fgets(), and friends (for truncation). There is a certain
level of anal checking that few coders seem willing to tolerate for long.

How often does one see the following code:

if(fclose(f) == EOF) { ... }

Exactly.

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.

A program that silently but predictably produces incorrect results can be
studied and fixed.

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


I believe my critic would agree with you.


Anyone who thinks a crashing program is a good program doesn't belong in
the industry.


The *** Heathfield we know and love has returned! This is what happens
when "How to Win Friends and Influence People" gets displaced by
"Trap Representations for Servos and Toasters".


Yours,
Han from China

Il mittente di questo messaggio|The sender address of this
non corrisponde ad un utente |message is not related to a real
reale ma all'indirizzo fittizio|person but to a fake address of an
di un sistema anonimizzatore |anonymous system
Per maggiori informazioni |For more info
https://www.mixmaster.it

.

Quantcast