RE: Order "begin" probes are run

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

On Friday, December 08, 2006 11:54 AM, fche@redhat.com wrote:
> "Stone, Joshua I" <joshua.i.stone@intel.com> writes:
>> [...]  Even changing [global initialization] to begin(-2^63) isn't
>> really correct, as it should happen *before* the beginning.  [...]
> 
> -2^63 is not actually a bad choice, and easily documented.  The more
> interesting ordering conflict is between this and
> module-parameter-based initialization.

Well, changing it to C-style initialization should be easy enough, and
seems more intuitive to me.  I'm not sure I understand the ordering
conflict you're talking about though.
 
> By the way, the new parse_literal variant does not check for numeric
> overflow for negative numbers quite right (running on x86-64):
> 
> % ./stap -p1 -e 'probe
> begin(-9223372036854775808),begin(-9223372036854775809) {}' # parse
> tree dump # file <input>
> probe begin(-9223372036854775808),
> begin(9223372036854775807){
> }

Yeah, I know.  It wraps around on the positive side too --
9223372036854775808 becomes -9223372036854775808.  (Side note - that's
one of the answers to an interesting CS question: what are the *two*
values of 'int64_t x' where x == -x?)

The same problem exists in other parts of the language as well:

$ ./stap -e 'probe begin { printf("%d\n", -9223372036854775809) exit()}'
9223372036854775807

In that case, it's being parsed as a positive that wraps around, and
then operated by a unary minus.  

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.


Josh