C problem, order of evaluation

diamond@tkovoa diamond at tkou02.enet.dec.com
Wed Apr 11 12:18:44 AEST 1990


In article <1990Apr10.195822.14808 at diku.dk> null at rimfaxe.diku.dk (Niels Ull Jacobsen) writes:

>      (stack[++sp] = g((stack[++sp] = make_cons(x,y), stack[sp -= 0]),
>                       (stack[++sp] = make_cons(x,z), stack[sp -= 0])),
>       stack[sp -= 2])

My stack just overflowed.  Let's try color coding.

>      (stack[++sp] = g((stack[++sp] = make_cons(x,y), stack[sp -= 0]),
        black brown      RRed  red                   orange           yellow

>                       (stack[++sp] = make_cons(x,z), stack[sp -= 0])),
                         GGrn  green                 blue              violet

>       stack[sp -= 2])
        gray     white

OK.
The red side effect (updating sp) must be completed before the orange comma's
sequence point.
The green side effect must be completed before the blue sequence point.
However, the yellow comma is not an operator and is not a sequence point.
Therefore green,red,orange,blue is a legal evaluation order.  (And many others.)
In fact, RRed and GGrn may be the same element of stack.

The brown side effect must be completed before the violet sequence point.
However, this may occur before, after, or intermixed with red, green, etc.

Gray and white are safe.  They leave the correct value in sp, and they fetch
the correct element of stack.  However, the correct element of stack might
not have been the target in assigning to black.

You asked for a fix to black, brown, gray, and white.  It might be possible.
However, red and green cannot be fixed.  You have to hack your expression
generator.

Now I'm going color-blind.

-- 
Norman Diamond, Nihon DEC     diamond at tkou02.enet.dec.com
This_blank_intentionally_left_underlined________________________________________



More information about the Comp.lang.c mailing list