RE: Order "begin" probes are run

["Stone, Joshua I" <joshua dot i dot stone at intel dot com>]

On Thursday, December 07, 2006 7:02 PM, Frank Ch. Eigler wrote:
> The change to unary number parsing is probably suspect though, in that
> it introduces parsing errors or ambiguities.  I thought we had a test
> for some instances of this problem.

There's definitely a token abiguity, as already noted in the lexer
comments -- should "1-1" be '1'+'-'+'1' or '1'+'-1'?  That's why I
didn't make the change in the lexer.

> If there is any doubt, I would suggest rolling this back, and let the
> probe point parser accept an explicit negation operator as an optional
> prefix.

Well, I implemented the check for negative in parse_literal, which is
near the bottom of the parsing stack.  There are three contexts where
this is called: global initialization and probe point parameters, where
binary operators aren't allowed; and parse_value, where both binary and
unary operators have already been accounted for.  If you can think of a
test case where this fails, please let me know.

We now get the bonus that global numeric initializers can be negative as
well.

However, I just noticed a bug, or at least surprise behavior, in the way
globals are initialized:

    global a = 42
    probe begin(-1), begin(1) { printf("%d ", ++a)

This will print "1 43 ".  It's not really a problem with the sequencing,
but it's because "global a=42" gets synthesized to "global a  probe
begin{a=42}" -- so the order that the initialization happens is
generally undefined.  Even changing it to begin(-2^63) isn't really
correct, as it should happen *before* the beginning.  I will file a bug
and investigate this.  There's a comment indicating that a C-initializer
might be the way to go, so I'll probably go that route.


Josh