Keith Thompson said:
I think you're misunderstanding what Richard said.
It think Richard revels in creating these misunderstandings.
I don't think any other regular manages to generate so many
long threads because of a subtle difference in the
interpretation of one word.
In fact, I suspect that everyone in this discussion is in
fundamental agreement about most things;
I'd say it's the fundamentals that we are in complete
disagreement over!
some of the concepts just aren't being communicated
clearly.
Both camps are perfectly clear. They're just incompatible.
As for strncpy() the function itself is not fundamentally
unsafe. Its semantics are precisely defined by the standard,
including the specification of cases where its behavior is
undefined. In contrast to gets(), it *can* be used safely
in well-written code.
Richard's point is there is no risk with gets, if you never
use it. That is perfectly true, but it is only barely
constructive.
It's true that it *can* be misused, but so can any
function.
Yes, but how can they be misused and why? Their very
existance creates risks, but additional risks are
involved to increasing degrees. There's very little
that can go wrong with exit(), there's quite a few
things that can go wrong with printf(), there's
almost nothing right about gets().
It's also true that, because of its misleading name, it's
particularly vulnerable
You mean it carries is a risk? Or do you see risk as a
stake, not a vulnerability?
to misuse by programmers who haven't
bothered to read and understand its specification (the
standard, a man page, whatever).
Things can go wrong for reasons other than 'not bothering'.
Risk analysis is a no-fault concept.
A just mopped floor can be slippery. An dirty unmopped floor
can be slippery too. The fundamental issue is that having a
floor for customers carries a risk. That risk needs to be
managed.
Richard would say there's no risk if you never let customers
walk on a dirty or just mopped floor. Perfectly logical. But
it offers no explanation of why you would do that, how you
achieve it, let alone what you need to do to cover the case
where you fail to achieve that.
Despite best intentions, customers will slip on floors. It's
because of attitudes like Richard's, that he wouldn't let
that happen, or that you shouldn't hire a stoor manager who
could let that happen, that many governments make public
liability insurance compulsory.
Because of that, any use of strncpy() should IMHO be viewed
with suspicion (like any use of a cast operator)
No Keith, there's no risk with cast operators either, if you
use them properly. Indeed, there is no risk with any aspect
of C, if you use it properly.
This is fatuousl^W trivially true, but it is not constructive.
And it certainly isn't the desired response from an interviewer
asking if the candidate can identify risks in a given function.
*unless* you're certain that the author actually knows what
he's doing.
What does certainty buy you? Even dmr has an errata page for
K&R2. If bwk can't be trusted to get it right first time, and
if Richard isn't available, who else could you possibly hire?
I strongly suspect that most uses of strncpy() in
production code are incorrect.
Yes, but why? If all you can think of is that programmers
can't be bothered, then you really do need to change your
mindset. [Whether you do so is, of course, in your hands.]
But that's not the fault of strncpy() itself, which is a
perfectly innocent little function
Again with the blame. It's not about knowing who's to blame.
It's about knowing what can go wrong, where possible why, and
what you do about it. Sometimes things go wrong for reasons
outside of your control. [Sometimes things go wrong because
you have too much control!]
Contenting yourself that to know if something goes wrong, it
will be clear who is to blame is not a constructive analysis
of the risks.
that does exactly what it's supposed to do.
Rain does exactly what it's supposed to do. It can still
disrupt Wimbledon. When that happens, it's not because
the tournament director couldn't be bothered preventing
the rain.
It's the fault of the incorrect assumptions made by too
many programmers.
Yes, yes, but how do you manage that? Don't hire people
with incorrect assumptions is one possibility, but unless
you make the interview 20 years long, you're not going
to be able to make the right call in all cases.
And those assumptions are partly the fault of the way
strncpy() doesn't fit well into the context in which
it's specified.
Richard does not equate weakness with risk. In other words,
whatever weakness you might spot in strncpy, it is incidental
because it is not the function weakness that introduces the
risk.
These long threaded misunderstandings, where apparently
everyone actually agrees, would be fewer in number if
Richard were just a little more flexible with regards
to recognising that people don't always use terminology
in precisely the same way that he does. Moreover, the
fact that others use terminology differently is not
because they are clueless.
