Keith Thompson <ks...@mib.org> wrote:
> 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.

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

--
Peter

Peter Nilsson said:

> Keith Thompson <ks...@mib.org> wrote:
>> I think you're misunderstanding what Richard said.
>
> It think Richard revels in creating these misunderstandings.

Well, no, Richard doesn't. What Richard *does* do is (try to) write his
replies to what was written, which isn't necessarily what was intended.
Richard is not a mind-reader, and so he usually tries to avoid guessing at
some hidden meaning concealed by the words of an article, and instead
takes them at face value. This means that he sometimes misses irony and
sarcasm (despite employing them freely, which makes him rather
hypocritical, but then - as he would say - we're all hypocritical, but
some of us are more honest about it!). He will, however, normally make
more effort to "interpret" the text if it's written by a newcomer who is
perhaps struggling to phrase his question in a way that he wouldn't if he
only knew exactly what the problem was. But when Richard replies to
articles written by people with more experience of programming in general
and C in particular, he is less prone to agonise over the text, trying to
discern the meaning behind the words.

Richard's attitude towards strncpy is this:

(a) it has a lousy name;
(b) there is rarely any point in using it;
(c) it is likely that most uses of it are flawed;
(d) there are occasions on which it is The Right Thing;
(e) because of (c), it is tempting to advise people to eschew it
completely, but because of (d), he thinks that a better solution would be
to educate people about its proper use and to correct their misconception
that it is a "safe" strcpy.

<snip>

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

Actually, Richard's point about gets is that you should never use it,
because it *cannot* be used safely.

<snip>

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

Right. So it is necessary to mop the floor *properly* - which, in this
case, means in a timely manner, so that it has time to dry before the shop
opens. Likewise, it is necessary to use strncpy properly (if you use it at
all) - which means it is necessary to understand what it does.

> Despite best intentions, customers will slip on floors.

Well, there's no ing some people. :-)

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

Richard disagrees. Richard's attitude is that the floor should be given
enough time to dry before customers are allowed to walk on it. If
Richard's attitude prevails and the floor *is* given time to dry,
customers won't slip on a wet floor (because there won't *be* a wet
floor). It is because of attitudes *not* like Richard's (e.g. "oops, we're
late with the floor-cleaning but what the hey, who cares, right?") that
people slip on wet floors.

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

And since most people don't use C properly, we should treat all C code with
suspicion. And Richard does! :-)

<snip>

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

Lousy analogy - buffer overruns (say) are not an arbitrary phenomenon that
might happen to your code. They are controllable. The programmer can't
stop buffer overrun attempts any more than the tournament director can
stop the rain but, unlike the TD, the programmer is in a position to
prevent the bad effects of such attempts.

>> It's the fault of the incorrect assumptions made by too
>> many programmers.
>
> Yes, yes, but how do you manage that?

FIRE THEM ALL! Bwahahahahahahahahaha!

Er, sorry - Richard means, hire the right people, people who are bright,
skilful, and flexible. Have at least one Pedantic S.O.B. on the team and
preferably two. (That could actually be their job title, right?) Have at
least one of them in on every code review, and review *all* code. And
value correctness over feature counts.

<snip>

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

Richard thinks these long threaded misunderstandings would be a lot shorter
if everyone just accepted that Richard Is Always Right (for a certain
value of "Richard", obviously[1]). Can we, at least, all agree on *that*?


[1] And, alas, for a certain value of "Always".

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

Richard Heathfield <rjh@see.sig.invalid> writes:
[...]
> Er, sorry - Richard means, hire the right people, people who are bright,
> skilful, and flexible. Have at least one Pedantic S.O.B. on the team and
> preferably two. (That could actually be their job title, right?) Have at
> least one of them in on every code review, and review *all* code. And
> value correctness over feature counts.
[...]

Are you hiring Pedantic S.O.B.s?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>

No, seriously, are you hiring?

Keith Thompson said:

> Richard Heathfield <rjh@see.sig.invalid> writes:
> [...]
>> Er, sorry - Richard means, hire the right people, people who are bright,
>> skilful, and flexible. Have at least one Pedantic S.O.B. on the team and
>> preferably two. (That could actually be their job title, right?) Have at
>> least one of them in on every code review, and review *all* code. And
>> value correctness over feature counts.
> [...]
>
> Are you hiring Pedantic S.O.B.s?

I already have more than enough PSOBs, thanks! :-)

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

Richard Heathfield wrote:

> Richard's attitude towards strncpy is this:
>
> (a) it has a lousy name;
> (b) there is rarely any point in using it;
> (c) it is likely that most uses of it are flawed;
> (d) there are occasions on which it is The Right Thing;
> (e) because of (c), it is tempting to advise people to eschew it
> completely, but because of (d),
> he thinks that a better solution would be
> to educate people about its proper use
> and to correct their misconception that it is a "safe" strcpy.

I have never written a program that used strncpy,
except as an academic exercise.

How often do you use strncpy, Dr Heath Field?

--
pete

pete said:

> Richard Heathfield wrote:
>
>> Richard's attitude towards strncpy is this:
>>
>> (a) it has a lousy name;
>> (b) there is rarely any point in using it;
>> (c) it is likely that most uses of it are flawed;
>> (d) there are occasions on which it is The Right Thing;
>> (e) because of (c), it is tempting to advise people to eschew it
>> completely, but because of (d),
>> he thinks that a better solution would be
>> to educate people about its proper use
>> and to correct their misconception that it is a "safe" strcpy.
>
> I have never written a program that used strncpy,
> except as an academic exercise.
>
> How often do you use strncpy, Dr Heath Field?

Well, I've just checked my current code base here, and can't find any
instances at all. That doesn't mean I won't find instances in older code,
and it doesn't mean I've never used it "on site", so to speak, but it does
seem that I rarely if ever use it. It is entirely possible that, like you,
I have never called it in production code. I don't recall ever doing so,
anyway. But I do know how it works, and I know how to use it if ever the
need should arise. :-)

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