Re: issue COMPILE-ENVIRONMENT-CONSISTENCY

[cperdue@Sun.COM (Cris Perdue)]

> Date: Mon, 5 Sep 88 15:38:42 PDT
> From: cperdue@Sun.COM (Cris Perdue)
> 
> > For me, discussing the subject in terms of permitting the compiler
> > to "wire in" ("bind names", etc.) information makes more sense and
> > is less restrictive than permitting the ocmpiler to assume that the
> > same "information" will be present at runtime.
> 
> Yes, that is another way to look at it.  However, not all compilers
> will actually "wire in" all the information they are permitted to, and
> instead rely on the definitions of types, functions, etc. as they
> exist at runtime.  In order to get the same behavior in all
> implementations, it's up to the user to make sure that the same
> definitions are present at run time as at compile time.  I think that
> something I didn't quite make clear in my original draft is that it
> "is an error" if the things listed in section 2 are not defined
> consistently.
> 
> -Sandra

Sandra's reply is quite apropos as far as I am concerned, and her
point that the compiletime and runtime environments must be consistent
to be sure of the same results in different implementations I agree
with.

I would still prefer to see implementations given a set of discrete
choices:  for certain cases the compiler is licensed to either "bind in"
or not bind in information available at compile time.  This implies
that runtime behavior may vary, but only to a certain degree.  For
various things there is no telling whether the compile-time or the
run-time binding will take precedence, but segmentation violations,
deleting all your files, etc., are not among the options.  Saying
that inconsistency "is an error" licenses implementations to
crash and burn, and that seems unnecessary here.

				-Cris