maine@pioneer.arc.nasa.gov (Richard Edwin Maine D-OFA) (03/17/89)
Keith Bierman writes: >In article <22754@ames.arc.nasa.gov> maine@pioneer.arc.nasa.gov.UUCP (Richard Edwin Maine D-OFA) writes: >> >> >>As an aside, has anyone noticed that the draft 8X standard (at least >>the Jun 87 version that I have) DOES require the compiler to provide >>diagnostics for code that violates the standard? I've never seen >> ... > >I have not yet studied the current draft (to be voted on in May), but >the general rule of thumb is as f77... define standard conforming >PROGRAMS, not compilers (a standard comforming compiler is that thing >which compiles the entire class of standard comforming compilers >correctly). That is also my general impression of the intent. The following stuff from the June 1987 S8.104 draft somewhat surprised me and was what lead to my question. All this is from section 1.4, Conformance. > ...specified in this standard refer PRIMARILY (emphasis mine) to > permissable forms and relationships for a standard-conforming > program rather than for a processor. The general thrust is clear above, but the "primarily" leaves a little room for leeway. A paragraph later: > A processor conforms to this standard if: > (1) It executes any standard-conforming program... > (2) It contains the capability to detect and report the use within > a submitted program unit of a form designated herein as deleted, > obsolescent, or deprecated, insofar as such use can be detected > by reference to the numbered syntax rules and their associated > constraints. (I assume the references to deprecated, etc. may not be relevant to the current draft, but that's irrelevant to my main point). > (3) It contains the capability to detect and report the use within > a submitted program unit of any additional form or relationship > that is not permitted by the numbered syntax rules or their > associated constraints. > However, a processor is not required...(a picky exception)... > > A standard-conforming processor may allow additional forms and > relationships... It is item (3) that caught my eye. Although the last sentence above does say that extensions (additional forms and relationships) are allowed, my reading and reconciliation of that statement with item (3) is that there must at least be an option (capability) to put out warning messages about the usage of such extensions (and presumably also about usages that are illegal both per ANSI and the extensions). Such an option does exist in many (not all) existing compilers, and I agree it is a reasonable way to handle extensions - allow them, but also provide a way for the user to detect them if desired. Admitedly my former wording was a bit broad and did not say anything about the numbered syntax rules and their constraints, but those rules and constraints do cover a big chuck of the standard. Am I reading more into this clause than is really there? I'm not 100% sure of my interpretation, but that's what it looks like it is saying. P.S. Sorry about flaming Calvin about his "patch" to the DO-loop program. I mistook it as a serious proposal. It didn't deserve a flame anyway. And yes, I know my fix was "obvious to the casual observer", which is why I was surprised that anybody proposed anything different. Rich Maine maine@elxsi.dfrf.nasa.gov (preferred) maine@pioneer.arc.nasa.gov (alternate)