🚀 go-pugleaf

In article <4ckms5$rd7@news.informix.com>
           dwood@informix.com "Daniel Wood" writes:

>Someone has pointed out(Besides my return address being wrong) that the
>correct term in the following is "undefined behavior" not "undefined result"
>and that the behavior stems from trying to store the value in the object.

No, the undefined behaviour stems from the calculation of the value. If f
were simply defined as:

void f(int x, int y)
{
    x-y;
}

it would still result in undefined behaviour.

>One of the undefined behaviors could be to core dump.

True, and that might happen as a result of an arithmetic overflow exception,
but doesn't have to.

>That still avoids the question of once we have stored something into "r"
>below and the program has NOT core dumped whether it is then acceptable for
>everything >and anything after that to exhibit undefine behavior beyond the
>act of storing the value.

Once you have invoked undefined behaviour you can say nothing about the
behaviour of the program from that point on.

>ORIGINAL MESSAGE FOLLOWS:
>
>THE TEST CASE, on SCO:

'SCO' is a little woolly here. You could be using (Microsoft based) cc,
(SVR4 based) cc, rcc, icc or gcc. I managed to get the behaviour you describe
with icc. The assembler listing is interesting but not really relevant to 
comp.std.c (in the first case it does a test based on the subtraction, in
the second case the value of the result is tested. Where the subtraction
is valid these will have the same effect).

>main() { f(-2147483647, 1879048192); }
>
>f(int x, int y) {
>        int r;
>
>        if ((r=(x-y)) > 0)
>                printf("1: r greater than 0\n");
>
>        if (r > 0)
>                printf("2: r greater than 0\n");
>}
>
>On SCO only the second print occurs.  The reason given to me is that ANSI
>states
>that the result of an overflowing/underflowing operation is undefined.  The
>implementation is free to do what it wants with the result.

It is the behaviour that is undefined, not the result (well, if you get a
result that will be undefined too).

> This is fine
>with me, however int's, unlike floats, have NO undefined bit patterns

Not true (at least not for signed integer types) - i.e. the standard
doesn't prohibit undefined bit patterns.

>and
>no matter what you do with the undefined result(Scramble the bits for all
>I care) once you store that something into an int variable that int
>is NOT undefined and allowed to exhibit volatile behavior.

It is once undefined behaviour has occurred in the program.

>Saying a result is undefined "IS NOT EQUAL TO" saying that a C int variable
>can actually hold an undefined value.

A conforming implementation might detect some forms of undefined behaviour
in a program and set a flag which causes random numbers to be applied to all
subsequent operations.

> If you think the test case is running
>acceptably, as described above, then tell me the section of the standard that
>states or implies that an int variable can hold an undefined value.

Not relevant.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------