Hi,

Reading the Standard:

<<1.3.14 well-formed program
  a C++ program constructed according to the syntax rules,
  diagnosable semantic rules, and the One Definition Rule (3.2).>>

(notice there is nothing about undefined behavior in the above
paragraph)

<<1.4 Implementation compliance

  The set of diagnosable rules consists of all syntactic and
  semantic rules in this International Standard except for those
  rules containing an explicit notation that "no diagnostic is
  required" or which are described as resulting in "undefined
  behavior.">>

Now, does that mean that the constructs for which there are no
diagnosable rules should be _ignored_ while determining the
well-formedness of a program?

Or does it mean that the use of constructs for which there are
no diagnosable rules makes a program ill-formed (not well-formed)?

Thank you.

Victor
--
Please remove capital A's from my address when replying by mail


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <96cafg$jo0$1@nnrp.atgi.net>,
Victor Bazarov <vAbazarov@dAnai.com> wrote:
>Hi,
>
>Reading the Standard:
>
><<1.3.14 well-formed program
>  a C++ program constructed according to the syntax rules,
>  diagnosable semantic rules, and the One Definition Rule (3.2).>>
>
>(notice there is nothing about undefined behavior in the above
>paragraph)
>
><<1.4 Implementation compliance
>
>  The set of diagnosable rules consists of all syntactic and
>  semantic rules in this International Standard except for those
>  rules containing an explicit notation that "no diagnostic is
>  required" or which are described as resulting in "undefined
>  behavior.">>
>
>Now, does that mean that the constructs for which there are no
>diagnosable rules should be _ignored_ while determining the
>well-formedness of a program?
>
>Or does it mean that the use of constructs for which there are
>no diagnosable rules makes a program ill-formed (not well-formed)?

Most of these things refer to run-time situations that cannot be detected
statically from the program text.  For instance, the statement:

    a = *p;

may appear in a well-formed program (assuming appropriate declarations of
the identifiers), but if p is null or indeterminate at the time that the
statement is executed, the behavior is undefined.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Victor Bazarov wrote:
>
> Hi,
>
> Reading the Standard:
>
> <<1.3.14 well-formed program
>   a C++ program constructed according to the syntax rules,
>   diagnosable semantic rules, and the One Definition Rule (3.2).>>
>
> (notice there is nothing about undefined behavior in the above
> paragraph)
>
> <<1.4 Implementation compliance
>
>   The set of diagnosable rules consists of all syntactic and
>   semantic rules in this International Standard except for those
>   rules containing an explicit notation that "no diagnostic is
>   required" or which are described as resulting in "undefined
>   behavior.">>
>
> Now, does that mean that the constructs for which there are no
> diagnosable rules should be _ignored_ while determining the
> well-formedness of a program?

I don't think it's actually possible to have a construct for which there
are no diagnosable rules - the syntax rules are always applicable, and
(barring defects in the standard) should always be diagnosable.

There might be a construct that has no diagnosable semantic rules
applying to it. However, you still can't ignore that construct - the
syntax rules and the One Definition Rule still apply to it.

> Or does it mean that the use of constructs for which there are
> no diagnosable rules makes a program ill-formed (not well-formed)?

No.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"James Kuyper Jr." wrote:
>
> There might be a construct that has no diagnosable semantic rules
> applying to it. However, you still can't ignore that construct - the
> syntax rules and the One Definition Rule still apply to it.

Yes, but it's possible to have valid syntax and compliance with the ODR
and still violate diagnosable semantic constraints of the language.
Dereferencing a pointer that doesn't point to a valid object is a
perfect example of this.  In general there is no way to diagnose this
at compile time (nor is the implementation required to do so).

>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Victor Bazarov writes:
[ ... ]
> Now, does that mean that the constructs for which there are no
> diagnosable rules should be _ignored_ while determining the
> well-formedness of a program?
>
> Or does it mean that the use of constructs for which there are
> no diagnosable rules makes a program ill-formed (not well-formed)?

I would imagine that the rule means that such constructs MAY render
a program ill-formed, but the standard imposes no requirement on
the implementation that they should do so.

Consider, for example, the common (erroneous) practice of using include
guards that start with two leading underscores.  Such names are reserved
to the implementation, and lead to undefined behaviour if defined by a
user.  If the programmer's name actually happens to cause a conflict, it
may result in the programmer's header not being included, and that in
turn may cause the program to be ill-formed.  On the other hand, most
of the time this does not result in a conflict, and compilers are not
required to verify that the user has not defined such a name.  In such
cases the standard allows the compiler to consider the program well-formed.

Mike

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]