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