note sundialsvc4 Probably the key improvement here is the use of hexadecimal notation:   <tt>0xffffffff</tt> instead of the corresponding, “magic” decimal.   As long as you are very careful to use unsigned arithmetic and specify bitmasks that are no larger than the integer-size you know that you are using, code like this ought to be transportable.   (It might not be readable, heh, but it ought to be <tt>int</tt>-length agnostic.) I would almost edit my comment to say, don’t use “arithmetic” at all when you are bit-twiddling, as in code like this: <code>$num = $num - 4294967296 if $num > 4294967295; $num = $num + 4294967296 if $num < -2147483648;</code>   That’s nasty...   And I recognize at least one of those numbers, <tt>-2147483648</tt>, as an old, familiar 32-bit friend.   I also detect the presence of signed arithmetic, dependent upon the thirty-first bit being the sign-bit.   I suggest that this code should be rewritten to use bit-masking operators ... and to do so, perhaps, in a very specific way, as follows: If you want to mash-off, say, all but the rightmost 31 bits of an integer quantity, you should take:   <tt> qty := qty and ( not 0x7fffffff );</tt>.   (I am not using Perl notation here, for clarity.)   The subexpression, <tt>(not 0x7fffffff)</tt>, will evaluate to an <tt>int</tt> in which all bits are <tt>1</tt> except for the rightmost 31 bits, and it will do so correctly no matter what the <tt>sizeof(int)</tt> may be. So, I suggest that you need to go through code like this (fortunately, it is a small piece of code), work out what it is doing and then rewrite it.   Construct a very thorough set of [mod://Test::More] cases that you can run on both a 32-bit and a 64-bit system to prove that your rewrite is thoroughly correct. 947353 947353