🚀 go-pugleaf

kanze@gabi-soft.fr (J. Kanze) wrote:
>Sean A Corfield (sean@corf.demon.co.uk) wrote:
>
>|> I've highlighted the important difference. Unspecified means it'll work
>|> fine but we're not telling you how; undefined means it might do anything
>|> (including not work at all).
>
>I see what you and Steve Clamage are getting at, but strictly speaking,
>from a standards point of view, is there any real difference?  If I
>understand you correctly, unspecified means that it will work, but the
>standard does not define what `work' means in this context.  So if it
>formats my hard disk (to take the classical example), the vendor can
>simply say: it's not a bug, that's our definition of work.

No, thats not how it goes. Here's how it goes. GIVEN a particular
implementor binding of the "implementation-defined" parameters
of the abstract machine, each well formed program is required
to exhibit one of a certain set of behaviours (or the compiler isn't
conforming).

0 elements: If the set is empty, the Standard is screwed.

1 element: If the set has exactly one element, the program is said to be
deterministic (contingent on the state of the environment).

SUBSET: If the set is a strict subset of the universal subset,
the program is said to be non-determinisatic and the
corresponding behaviour is said to be "unspecified".
This is misleading because the SET of permitted behaviours
is NOT unspecified, contrarily the range of permitted behaviours
is ALWAYS specified in the Standard (or the Standard is screwed).

UNIVERSAL SET: If the set is the universal set, the program is said to
have undefined behaviour. This is sometimes explicitly
stated, although such statements are always non-normative.
Where it is not possible to deduce anything about the required
behaviour from the Standard, then behaviour is undefined,
which is "undefined behaviour".

SO: it is very simple. You can say "the Standard specifies
the SET of behaviours of ALL well formed programs precisely."
The terminology "well defined", "unspecified" and
"undefined" simply refers to the SIZE of that set, nothing more.

[Caveat: note again that this applies to a particular binding
of the Standard by an implementor; and also that behaviour
is contingent on the environment. Note further that the behaviour
of YOUR program may be more restricted than specified by the
Standard: you may well (have to) rely on non-portable implementation
specified properties of your compiler or envionment.]

-- 
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. ]