🚀 go-pugleaf

In article <TANMOY.96Jan23090015@qcd.lanl.gov>,
Tanmoy Bhattacharya <tanmoy@qcd.lanl.gov> wrote:
>--text follows this line--
>In article <4e2eo4$ogq@lyra.csx.cam.ac.uk> nmm1@cus.cam.ac.uk (Nick
>Maclaren) writes: 
><snip>
>   This is a very good question.  I understand the standard to imply
>   that all previous defined behaviour must have 'occurred', but
>   there is (in general) no necessity for it to have had an effect
>   on the outside world (assuming that such a thing exists).  Some
>   constructions (e.g. fflush()) require effects to be transmitted
>   to the environment.
>
>Could you please elaborate on this? 3.16 seems to be saying that the
>behaviour of the program is undefined. It refers to both translation
>and execution phases, and even allows the translation to terminate: in
>which case there is no execution at all! I think a compiler core
>dumping is as conforming a response as the program starting with the
>program starting with an attempted execution of Bach, presumably
>because the compiler ignored the possibility and that led to a bizarre
>executable. 
>
>So, I do not understand how you can demand `previous' defined
>behaviour to have occurred? Previous to what? Previous to the
>attempted translation of the construct leading to undefined behavior? 

No, of course not.  The majority of circumstances that lead to undefined
behaviour are inherently associated with execution - i.e. whether the
program is conformant or not will depend upon the data, and cannot be
determined during translation.  You are correct that the standard's
wording allows a translator to detect undefined behaviour and, having
done this, to go bananas rather than actually diagnosing the fault.
But that is gratuitously perverse.

As you know, there IS an inherent order implied during execution
(though it is mathematically pretty horrible, being a set of vaguely
compatible partial orders).  I am referring to the case where the
undefined behaviour is either not determinable or not detected during
translation, and hence the execution chronology becomes relevant.
In general, this is the interesting and practical case.


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679