🚀 go-pugleaf

In article <4a2nvl$nq@natasha.rmii.com> jcoffin@rmii.com (Jerry Coffin) writes:

> Not really.  Consider a real example of unspecified behavior:
> 
> 	a = b + c + d;
> 
> Now, it is unspecified whether the multiplication will be evaluated
> before or after the division.  Under some circumstances, you may even be
> able to detect a diference.  (e.g. depending on the magnitudes involved,
> floating point accuracy can be affected.)

But this is an example where the standard gives a set of possible
behaviors; the behavior is unspecified, but is constrained to belong
to that set.

What concerns me is the case where the behavior is "unspecified" and
the standard imposes no constraints at all.  In that case, it might as
well just call the behavior "undefined"; I don't think the two terms
mean anything very different in that case.  The main difference seems
to be one of connotation and emphasis, rather than any specific
requirement on implementations.
-- 
  Matt Austern                             He showed his lower teeth.  "We 
  matt@physics.berkeley.edu                all have flaws," he said, "and 
  http://dogbert.lbl.gov/~matt             mine is being wicked."

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