Re: [Lit.] Buffer overruns
From: Douglas A. Gwyn (DAGwyn_at_null.net)
Date: 12/28/04
- Next message: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Previous message: infobahn: "Re: code cracking or how do you know you've got the correct key?"
- In reply to: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Next in thread: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Reply: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 27 Dec 2004 23:33:24 -0600
Mok-Kong Shen wrote:
> But the result of the statement is 'undefined' in that situation.
> So, if the condition a[i]==i is not checked, then this could
> lead to something wrong. Are you suggesting that it is the
> user's responsibility to explicitly check that to avoid such
> undefined cases?
It is certainly the programmer's responsibility to avoid
triggering instances of undefined behavior. If you're
unwilling to learn the modest amount required to fulfill
such a responsibility, it would be best if you refrained
from programming.
> Using pointers in the C way is inherently unsafe.
Wrong. A very large number of programmers use them
quite safely.
> That's why I called it a 'pitfall'.
Of course it's a pitfall. Reasonable people *avoid*
pitfalls. One doesn't have to shun an entire PL
just because it requires care in certain cases.
In fact all PLs require some degree of care if
correct results are to be obtained.
> Perhaps it is also the case that no skilled programmer is
> a substitute for a PL designed for safety of programming and
> void of pitfalls.
Wrong again. The history of PL development is full
of examples where an attempt was made at automating
some property like safety, without the goal actually
being obtained. No compiler can read your mind (or
better, the minds of the end users) to determine what
the actual intent of the instructions is. They have
to go by what the programmer specifies, which if it
is incorrect will produce incorrect results.
>> I think average users will struggle with C. C programmers, however,
>> should not. It's a great pity when they don't live up to expectations.
> You are 'defining' the problems away.
No, he isn't. He's saying that it is reasonable to
require craftsmen to be masters of their tools.
You on the other hand seem to think that tools must
be built (somehow) to guarantee that unskilled and
undisciplined amateurs will always obtain quality
results. In any other discipline the absurdity of
that notion would be evident..
There is a difference between production and
consumption, and between the behaviors of the people
acting in those roles. In order to provide consumers
with better, eay-to-use products, producers usually
need to do some hard work (which the consumer doesn't
see and often is unaware of).
- Next message: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Previous message: infobahn: "Re: code cracking or how do you know you've got the correct key?"
- In reply to: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Next in thread: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Reply: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
