Re: Order "begin" probes are run

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

On Fri, Dec 08, 2006 at 12:18:32PM -0800, Stone, Joshua I wrote:
> [...]
> Well, changing it to C-style initialization should be easy enough, and
> seems more intuitive to me.  

OK.

> I'm not sure I understand the ordering conflict you're talking about
> though.

For some time now, we have had code to set some script globals at
module-load using module options.  This initialization step should
probably be defined to take place at priority 0, but uses a different
mechanism.  Thus, the probe-based and module-parameter-based
initializations could have ordering problems.


> Yeah, I know.  It wraps around on the positive side too --
> 9223372036854775808 becomes -9223372036854775808.  [...]

That's a little less bad.

> The same problem exists in other parts of the language as well:
> $ ./stap -e 'probe begin { printf("%d\n", -9223372036854775809) exit()}'
> 9223372036854775807

This is another one of those cases where I could've sworn that there
was a parseko test case.

> [...]  It's not obvious to me that there's a right thing for the
> translator to do in either case.  It's up to the programmer to know
> that there are limits to 64-bit numbers.

I would prefer the parser to accept -2**63+1 ... 2**63-1 for literals
everywhere.  To get -2**63, one would have to use the same construct
that you will find in <limits.h> for foo_MIN values, e.g.:

   #define INT_MIN       (-INT_MAX-1)

This would make that value unsuitable as a strict literal.  This could
in turn come in handy as an encoding of the explicit 

   global var=5

initialization.

- FChE