🚀 go-pugleaf

In article <44u2h1$362@rdsunx.crd.ge.com>, volpe@bart.crd.ge.com (Christopher R. Volpe) writes:
|> In article <44u0jm$9pr@lyra.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
|> >
|> >When talking on C, I use a related construction as an example of something
|> >that is simultaneously illegal and required to work.  I.e. a conforming
|> >compiler may reject the program but, if it fails to detect the error, the
|> >compiled code must execute correctly.
|> 
|> I have a hard time understanding this. If the code is "illegal" in the sense
|> of requiring a diagnostic, then a conforming compiler MUST detect and diagnose
|> the error. If it doesn't, then it  isn't a conforming compiler, and all bets
|> as to what the resulting code must do are off.

I didn't say that it was required to produce a diagnostic.  There are
several kinds of illegality in ANSI C that need not be diagnosed.

|> Even if it detects the error, and generates code, how can you justify
|> any claim about what illegal code "must" do?

Try 3.1.2.5 "The qualified and unqualified versions of a type are distinct
types that belong to the same type category and have the same representation
and alignment requirements." and footnote 15 "The same representation and
alignment requirements are meant to imply interchangeability as arguments to
functions, return values from functions, and members of unions."  Follow on
from there.

In any case, I was talking about when it FAILS to detect the error!

|> >There is actually some dissent about this.  Some people hold the view that
|> >implementation-defined behaviour allows the compiler writer to say "if you
|> >use this construction, you will get no error message and your program will
|> >go bananas."  This is clearly not what the ANSI committee intended compiler
|> >writers to do :-)
|> 
|> Correct, but what exactly is implementation defined in the example you gave?

Assigning a value to a 'const int *' initial member and reading it as an
'int *' etc.  Because these are not compatible types, 3.3.2.3 makes the
effect implementation-defined.


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