🚀 go-pugleaf

In article DM4@falcon.daytonoh.attgis.com, Dick Menninger <Dick.Menninger@daytonoh.attgis.com> writes:
> 
>I have never disagreed with "undefined" absolving
>compilers of the responsibility of detecting the fault.
>My real issue is different, actually, and I am speaking
>it as programmer who will be using the resulting
>compilers.  What I want the DWP to do specify is:
>if a compiler goes ahead and detects faults in an
>"undefined" case in spite of not needing to do that,
>THEN they are constrained to do the three actions.
>If the compiler does detect and then do active
>malicious things that have not been pre-announced,
>I want it to be considered non-conforming behavior.
>As a potential victim of such a practice, I want to
>have available the only weapon the standard provides
>to aid in addressing such severe brain damage.
>Now that is not much to ask at all and does not
>make anything materially different in the standard.
>About all it does is take away the childish (in the bad sense)
>statements some experts make about this topic,
>and that is a positive contribution, quite frankly.

First of all, I don't know how one could specify in any meaningful
way that a compiler shall not do malicious things. ("That wasn't
malicious; we had the very best of intentions." Do you want compiler
certification to be adjudicated by the courts?)

Second, I don't think it is possible to make the requirement that
implementations predict how they will respond to detected undefined behavior.
For example, suppose more than one thing is wrong with a section of code,
which is often the case. There would be many ways to interpret
what sort of errors are present, possbily including no undefined
behavior, or several different kinds of undefined behavior. (BTW,
that is why the standard only requires "a diagnostic message" if a
program contains any diagnosable errors. You cannot in general say
which errors a given erroneous program contains.)

Third, if you did make such a requirement, I believe it would be
counter-productive. The only feasible response from implementors would
be deliberately to ignore undefined behavior, since it isn't possible
to predict reliably how the compiler will respond to all possible program
inputs. It also isn't possible to test compilers for conformance to such a
requirement, since you would have to provide all possible inputs and see
whether the compiler responded as advertised. 

Finally, the "childish statements some experts make" are just the
rhetorical device of exaggeration for effect. Example: You write
code that stores a byte via an invalid char*, something that is not
normally detectable by the compiler anyway. By bad luck, the byte is
stored in a location that is not write-protected (an OS issue, not a
C++ issue) and which happens to contain the code for "seek disk". By
more bad luck, the byte code that gets stored is the one meaning
"erase disk". The next time any reference is made to the disk, it gets
erased. Malicious or predictable compiler behavior? Of course not. Possible
behavior? Yes. MSDOS users are all too familiar with the computer going
bonkers after a program failure. That's why the reset button is on the
FRONT of the computer. :-)

---
Steve Clamage, stephen.clamage@eng.sun.com



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