Re: [Lit.] Buffer overruns
From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 12/27/04
- Next message: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Previous message: Joe Peschel: "Re: code cracking or how do you know you've got the correct key?"
- In reply to: infobahn: "Re: [Lit.] Buffer overruns"
- Next in thread: infobahn: "Re: [Lit.] Buffer overruns"
- Reply: infobahn: "Re: [Lit.] Buffer overruns"
- Reply: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 27 Dec 2004 18:06:34 +0100
infobahn wrote:
> Mok-Kong Shen wrote:
>
>> infobahn wrote:
>>
>>> [...] The C Standard does not forbid such code; it merely does
>>> not define the behaviour of the code under the relevant
>>> circumstance.
>> O.k. I have used too strong a word. The fact remains that
>> the C standard declares the contruct to be undefined and so
>> the user is apparently expected not to employ it, just like
>> in common language the case where a word (typo or self-made)
>> is not in any dictionary.
>
>
> Nothing wrong with the construct, in this case. Just a reminder:
> we're talking about a[a[i]] = 1, in the special case where
> a[i] == i.
>
> The construct in question is "array indexing", and there's nothing
> undefined about it whatsoever (except in certain circumstances).
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?
>> Don't you think that a good compiler
>> should flag such usages instead of silently compile without
>> any warning?
>
>
> I think you expect more than is reasonable from your compiler.
>
> Consider this code:
>
> void f(int *m, int *n)
> {
> *m = *n++;
> }
>
> Would you require the compiler to diagnose this code? If so, why?
> If not, why not?
Using pointers in the C way is inherently unsafe. This may
be understood as a broad critque of the PL, which some others
in this thread have also expressed. On the other hand, this
example is in a sense particular. For people using pointer
arithmetics could (in general practice) be expected to be more
conscious of the dangers involved than in situations like
a[a[i]]=1, where more careful reading of the C standard
document, eventually needing help from experts. (The semantics
of pointers and their use is generally properly understood.)
That's why I called it a 'pitfall'.
>
>>> I think you need to get to grips with the meaning of the
>>> word "undefined". You seem to think that it means "won't
>>> compile" or something. It doesn't.
>>
>>
>>
>> See above. Maybe I as user expect too much from a good compiler.
>
>
> Yes, you do. No compiler is a substitute for a skilled programmer.
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.
>> But anyway the example is a pitfall for the average user
>> (who are not experts of the C standard document). Do you agree?
>
>
> 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.
M. K. Shen
- Next message: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Previous message: Joe Peschel: "Re: code cracking or how do you know you've got the correct key?"
- In reply to: infobahn: "Re: [Lit.] Buffer overruns"
- Next in thread: infobahn: "Re: [Lit.] Buffer overruns"
- Reply: infobahn: "Re: [Lit.] Buffer overruns"
- Reply: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
