Re: [Lit.] Buffer overruns

From: BRG (brg_at_nowhere.org)
Date: 12/21/04 

Date: Tue, 21 Dec 2004 09:37:35 +0000

Mok-Kong Shen wrote:

> Bryan Olson wrote:
>
>> Mok-Kong Shen wrote:
>> >
>> > Douglas A. Gwyn wrote:
>> >> Of course not, because *I* understand what is meant by
>> >> "undefined behavior" in the context of the C standard.
>> >
>> > Then please show us a complete C code (runnable on gcc)
>> > that demonstates the 'undefinedness' (in the context of
>> > what Olson said you had claimed earlier in other groups) or
>> > else explain clearly based on quotations of the C document
>> > that both the gcc and the VC++ ompiler had done wrongly in
>> > the case of my code (as given in my previous post).
>>
>> That doesn't make sense. When behavior is undefined there is no
>> wrong thing to do.
>
> You misunderstood me. I mean, if there is 'undefinedness',
> one should be able to show program pieces that either
> (1) the complier would complain, (2) different compliers
> would give different results, or (3) the same compiler
> would give different results on different runs. On the
> other hand, my code on two compilers give always the result
> that one actually theoretically expects. So, if Gwyn
> nonetheless claims 'undefindness', he should be able
> to show that, even though there should be 'undefinedness'
> according to the standard, by chance the compilers
> produced such results (i.e. two errors committed by the
> compilers happened to cancel each other).

This 'undefinedness', as you call it, is set out in the C standard and
this means that even if all existing standard conforming C compilers
produce exactly the same result it _still_ remains undefined.

Anyone who produces a new standard conforming C compiler does not have
to match these existing results and those who want to offer standard
conforming C code cannot rely on this behaviour.

Your tests hence do nothing to resolve the issue - this behaviour is
undefined because the C standard _says_ it is, not becausde of what
compilers actually do.

>> > One wants here hard facts, not simply your personal
>> > 'understanding', which readers of the group can't 'see'
>> > (because that's in your brain), no matter how high your
>> > reputation as C expert is.

The C specification is openly available (and free in last draft form).
So you don't need to rely on anyone else's understanding - go and read
it yourself and you will see that this behaviour is undefined.

> If a construct employed is 'undefined' according to the
> wordings of a PL standard, then of course 'anything' could
> happen, if the compiled stuff gets run, ranging from wrong
> results to crash of the run, the latter being often the
> less evil. That's well known. (For example, the result
> of overflow in arithemetic operations may be explicitly
> stated in the standard to be 'undefined'.) Thus Gwyn should
> in the present case show (with reference to sentences in
> the standard document) his claimed 'undefinedness'.

I don't agree with DG on his general hypothesis in this thread (that the
contribution of tools to safety is not important because others issues
have more impact) but in respect of this particular issue he has done
all he needs to do to show that it is you and not he that is wrong.

>> > (I already expressed my
>> > conjecture in another post that you have very likely
>> > wrongly interpreted the C standard document, even though
>> > you are a committe member.)
>>
>> If there's anything more exasperating than debating with you,
>> Mr. Shen, it's being on the same side.
>
> This reflects your unsound attitude to sciences, unfortunately.
> You should argue purely on scientific grounds, independent
> of 'personal' matters, including who happen to be on your
> side and who happen to be on the opposite side. (Why should
> you as a scientist care such?).

Bryan Olsen's comment simply reflects the fact that you repeatedly post
gratuitiously on issues without ever making a real effort to understand
the fully satisfactory answers that you have already been given.

   Brian Gladman

Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... Bryan Olson wrote: ... my code on two compilers give always the result ... even though there should be 'undefinedness' ... wordings of a PL standard, ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... my code on two compilers give always the result ... even though there should be 'undefinedness' ... >> according to the standard, ... Even knowing the paragraphs, it ...
    (sci.crypt)
  • Re: the standard is so strange
    ... be able to 'explain' it in terms of the famous C standard. ... int main ... It looks like the compiler has fetched `*p1*` once, ... any order -- it is this freedom that the undefinedness is there ...
    (comp.lang.c)
  • Re: [Lit.] Buffer overruns
    ... >> This 'undefinedness', as you call it, is set out in the C standard and ... >> this means that even if all existing standard conforming C compilers ... I did not know of the example quoted before Bryan Olson introduced it. ... Even knowing the paragraphs, it ...
    (sci.crypt)
  • Re: GNU Fortran 95: Opinions?
    ... >> a compiler option if they choose to actually set some sort ... >> and still be perfectly standard conforming. ... >> Dick Hendrickson ... > path to undefinedness and the several vendors with undefined checking ...
    (comp.lang.fortran)