Doc. No.:       X3J16/95-0106
                                                  WG21/N0706
                                  Date:           May 30, 1995
                                  Project:        Programming Language C++
                                  Reply To:       Patrick Smith
                                                  pat@tesuji.qc.ca
 
               Wording in Conformance definitions
 
  These are some suggestions for improving the wording of some of
  the text in Chapter 1 touching upon conformance issues.
 
 
  About the definitions of implementation-defined, unspecified, and
  undefined behaviour in 1.3:
 
     These terms are explained in more detail in 1.8, so the definitions
     in 1.3 should have references to 1.8.
 
     The mention of correct/erroneous programs and data in these
     definitions is confusing.  There seems to an assertion here
     that programs with implementation-defined or unspecified behavior
     are "correct" in some sense, but it is not clear what sense is
     intended.
 
     Since there are better definitions of these terms in 1.8,
     I suggest simply removing the references to correct and
     erroneous programs?
 
     The examples in the definition of "undefined behavior" are a bit
     confusing.  The juxtaposition of "behaving ... in a documented
     manner (with or without ... a diagnostic ...)" and "terminating
     ... execution (with ... a diagnostic ...)" suggests that, if the
     program is terminated, there must be a diagnostic.  Producing
     a diagnostic is certainly a good idea, but should not be required.
     I suggest added "or without" to the last parenthesized phrase.
 
  If we apply all the above suggestions, then these three definitions
  would become:
 
     -- implementation-defined behaviour:  Behaviour that depends on
        the implementation and that each implementation shall document
        (1.8).  The range of possible behaviours is delimited by the
        standard.
 
     -- undefined behaviour:  Behaviour for which the standard imposes
        no requirements (1.8).  Permissible undefined behaviour ranges
        from ignoring the situation completely with unpredictable
        results, to behaving during translation or program execution
        in a documented manner characteristic of the environment
        (with or without the issuance of a diagnostic message), to
        terminating a translation or execution (with or without the
        issuance of a diagnostic message).
 
     -- unspecified behaviour:  Behaviour that depends on the
        implementation.  The implementation is not required to
        document which behaviour occurs (1.8).

                                                                     Page 2
 
 
  The definition of unspecified behaviour in 1.3 says "usually the
  range of possible behaviours is delineated by the standard."
  1.8p3 says "In each case ...".  These two sections should agree
  on whether it is "usually" or "always".  Unless we are confident
  that the standard does (or will) document the possibilities in
  every case, I suggest changing "In each case" in 1.8p3 to
  "In most cases".
 
 
  The term "diagnosable errors" is used in 1.7p2, but not defined.
  Perhaps we could change the end of 1.7p1 to
 
     ... that contains a diagnosable error, except as noted in this
     International Standard.  A diagnosable error is a violation
     of any diagnosable semantic rule or of any syntax rule.