Fwd: [Pnet-developers] Porting work remaining question

[Peter Colson]

Begin forwarded message:

> OK. I've found some strangeness:
>
> If stacktop = 80040dd2e8
>
> Then:
>
> &(stacktop[-1]) = 80040dd2e0
> stacktop-1 = 80040dd2e0
>
> Which is the same. But using expanded CVM_WORDS_PER_LONG:
>
> &(stacktop[-((sizeof(ILInt64) + sizeof(CVMWord) - 1) / 
> sizeof(CVMWord))] = 88040dd2e0
> stacktop-((sizeof(ILInt64) + sizeof(CVMWord) - 1) / sizeof(CVMWord)) = 
> 80040dd2e0
>
> Which re-introduces the difference seen above.
>
> This seems to be either precedence (which I doubt as everything
> including final result is bracketed prior to negation) or something
> in the evaluation of 8+8-1/8? I'll keep looking, but if there's 
> anything
> obvious, let me know.

Further details, possible fix...

On line:

&(stacktop[-CVM_WORDS_PER_LONG])

compiling under Wintel/VC7.1 shows:

warning: unary minus operator applied to unsigned type, result still 
unsigned
warning: integral constant overflow

If I apply a signed int cast to the final macro result everything is 
fine. As a
short term fix I've changed CVM_WORDS_PER_LONG define to cast to
signed int.

This works for moment (ReadLong in COP_L2I doesn't crash). Do
you see this as an OK long-term fix? I'm undecided at this point...


Regards,
Peter Colson.