🚀 go-pugleaf

In article qvt@mulga.cs.mu.OZ.AU, fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>I don't think there is any disagreement about whether it IS undefined
>behaviour; the question is about whether it should be.  Remember, every
>instance in which the standard leaves the behaviour undefined is one
>more hurdle for programmers trying to write portable programs.  ...
>
>However, the argument that the behaviour should be undefined in order
>to support implementations which perform pointer validity checking in
>hardware is more convincing.

The language standard defines what a valid program is, and the meaning of
valid programs. A particularly difficult part is deciding what the required
response should be to an invalid program, or whether the standard should
try to specify a response.

Some things, like invalid pointers, are impractical or impossible to diagnose
until run time. (Impossible, even theoretically, for the general case.) Then
the decision becomes whether to require specific run-time behavior, or
constrain run-time behavior to a manageable set.

There isn't any way to predict in a platform-independent way what the
range of responses might be to using an invalid pointer, so the choices
boil down to requiring implementations in general to detect invalid
pointers at run time, or not requiring them to detect invalid pointers.

In my view, a requirement like "must raise a signal" as the response is
no better than requiring any other particular behavior. On some systems
raising a signal is the default hardware response and comes for free.
Other systems have no hardware detection or a different hardware
response, so run-time checks would be required to avoid unpredictable or
disallowed behavior. Loosening the requirement to "must raise a signal,
or do A or do B or do C" doesn't change the general case. What if some
platform, such as a system to be built years from now, normally reacts
by doing D?

"Undefined behavior" is the way the standard says, "We don't know a good
way to specify any set of behaviors for this invalid code, so we leave it
up to implementors to do something that satisfies their customers."

Put another way, "undefined behavior" is a hook that allows impelementors
to attach behavior that their customers want in handling potentially
invalid code. On a specific system, a particular response might be
expected which would be inappropriate on other systems.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]