🚀 go-pugleaf

martelli@cadlab.it (Alex Martelli) wrote:
>John Max Skaller <maxtal@suphys.physics.su.oz.au> writes:
>	...
>>>If that subclass is destroyed through a pointer to an ancestor whose
>>>dtor isn't virtual, undefined behaviour (violation of a "shall").
>
>>No no! Undefined behaviour is NOT a violation.
>
>No, but if the _program_ violates a "shall", undefined behaviour
>may result.

    NO. My point is that this is NOT the case (as I understand it).
A "shall" on the program is to be interpreted as a requirement
on the compiler to issue a diagnostic.

>>where behaviour is undefined is the one place
>>it is IMPOSSIBLE for a "shall" to be violated,
>>because there isn't one :-)
>
>5.3.5 verse 3 says "the static type shall have a virtual destructor or
>the behaviour is undefined"; 

    The wording in the Working Paper is NOT CONSISTENT (yet).
This clause is misworded. It SHOULD say "..if the static type
has a virtual destructor then ... (else behaviour is undefined)."

    Technically, in C++ there is NO notion of a conforming
program and the Working Paper can NOT "shall" a programmer.

    Unfortunately, much of the WP was lifted from the ARM
and the style therein addresses the programmer, 
(as is appropriate for a reference manual) rather
than the implementor (as is appropriate for the C++ Standard).
(ISO C addresses both, C++ quite specifically and 
deliberately does NOT).

    Andrew has suggested fixing this with minimal editorial
changes by _defining_ "the program shall X" to mean
"if the program is not X, it is ill formed" -- which is
a constraint on the compiler to issue a diagnostic.

   It is WOULD be possible to define a "shall" on the
program to mean "behaviour is undefined" INSTEAD. However, 
it CANNOT simultaneously mean  "ill formed if violated" 
because the two things a diametrically
opposed notions: "ill formed" programs require a diagnostic,
behaviour is completely deterministic, undefined programs
require no diagnostic, indeed, all requirements on the
implementor are waived.

>So, the undefined behaviour "is NOT a violation", but it can _follow_
>from a violation on the program's part -- therefore, it's QUITE
>possible for a "shall" to _have been_ violated (by the program)
>where behaviour is (becomes) undefined.

Only in that AFTER a diagnostic is issued for an ill
formed program, all constraints on the implementor 
are waived.

When the WP says "behaviour is undefined" 
(or simply fails to defined behaviour), then it
is usually being quite specific in saying the
there is NO POSSIBLE VIOLATION by the compiler:
all bets are off.

To understand this another way: given some code,
the WP _always_ defines a range of permitted
behaviours:

  1. Issue a diagnostic   ("Ill formed")
  2. Do exactly one thing  ("Deterministic")
  3. Do one of several things. ("Unspecified, non-deterministic")
  4. Do anything. ("undefined behaviour").


So "undefined behaviour" is just the universal set,
and specific behaviour is just a singleton set,
-- including "ill formed". Nothing is more different
than these two sets!

A compiler is conforming if and only if it produces
a behaviour in the specified set (and has appropriate
documentation of implementation defined stuff).

-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au



[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]