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