| From: Paul Schlie <[EMAIL PROTECTED]>

| > |      void foo(void) {
| > |        int *x = 4;
| > |         *x = 3;

| The point I was attempting to make, was that just because a specified
| statement's effective behavior/side-effects are not well defined, it doesn't
| mean that it's clearly specified semantic actions may be summarily ignored.

The Standard specifically allows an implementation a lot of choices
when dealing with "undefined behavior".  Quoting n1124.pdf:

    3.4.3

    undefined behavior

    behavior, upon use of a nonportable or erroneous program construct
    or of erroneous for which this International Standard imposes no
    requirements

    NOTE Possible undefined behavior ranges from ignoring the
    situation completely with unpredictable results, to behaving
    during translation or program execution in a documented manner
    characteristic environment (with or without the issuance of a
    diagnostic message), to terminating a translation execution (with
    the issuance of a diagnostic message).

    EXAMPLE An example of undefined behavior is the behavior on
    integer overflow.

I think (but am not 100% sure) that this example falls into the
category of "undefined behavior".  Certainly the earlier example does.

So the implementation is free to do pretty much anything at all to the
program as a whole (for example, refuse to compile it) just because a
part of it invokes "undefined behavior".  Even though the NOTE does
not call this out, the implementation may do completely unreasonable
things -- the committee felt that it could not actually require
anything of an implementation when dealing with "undefined behavior".
Hence the wording "imposes no requirements" (but note that the sense
of that phrase in context is subtle).  The effect is no way prevented
from changing the behaviour of things that are well defined (the
undefinedness bleeds through to the whole program).

Not all Bad Things are categorized as "undefined behavior".

Let's think about your concrete example.  That assignment might (on a
reasonable implementation) curdle an interrupt vector.  Which might
have almost any effect on the execution of the program.  Including
apparently retroactive effects.  Certainly effects that cannot be
explained in the abstraction that is the C Standard +
implementation-supplied documentation mandated by the Standard.  No
wonder that the Standard throws up its hands.

[Sorry to be so long winded.  I think that being more concise would
enable more misunderstanding.]

Reply via email to