🚀 go-pugleaf

Sean A Corfield (sean@corf.demon.co.uk) wrote:

|> In article <MATT.95Nov30185128@cyclops5.berkeley.edu>,
|> matt@cyclops5.berkeley.edu (Matt Austern) wrote:

|> |> Section 1.3 of the draft standard says that undefined behavior is
|> |> "Behavior, such as might arise upon use of an erroneous program
|>                                                  ^^^^^^^^^
|> |> construct of or erroneous data, for which the standard imposes no
|>                    ^^^^^^^^^
|> |> requirements."  It also says that unspecified behavior is "Behavior,
|> |> for a correct program construct and correct data, that depends on the
|>          ^^^^^^^                       ^^^^^^^
|> |> implementation.  The implementation is not required to document which
|> |> behavior occurs.  [Note: usually, the range of possible behaviors is
|> |> delineated by the standard.]"
|> |> 
|> |> Now, as I read these definitions it seems to me that they're the same,

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

I'd like to stress the point that I'm talking strictly about what the
standard guarantees here.  In real life, of course, no vendor is going
to intentionally reformat my hard disk.  On the other hand, if that
happens, it really doesn't matter whether the standard says that the
error was in my code or the vendors; my data are still gone.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
              -- A la recherche d'une activité dans une region francophone

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