Something like this should get you in the range. [...]

printf ("INT: +/- %d\n", sprintf ("%u", -1) / 2);

This didn't work for me; it printed:

INT: +/- -9223372036854775808

(platform = CYGWIN_NT-5.1 1.7.1(0.218/5/3))

Scary stuff.

Is this run under Windows XP-64 or 32?

Is 64 bit native in the OS? What perl distribution?

Replacing it with:

printf ("INT: +/- %d\n", sprintf ("%u", -1) / 2 - 1);

didn't help, surprisingly:

INT: +/- -9223372036854775808

^

Since this is supposed to be 'unsigned', its not too suprising.

But the following did the trick:

printf ("INT: +/- %d\n", sprintf("%u", -1)>>1);

INT: +/- 9223372036854775807

I don't know why division by 2 should be any different than >>1.

Because division is always done in floating point arithmetic in Perl.

So the result of (18446744073709551615/2) should be

9223372036854775807.5 - but that isn't representable in a 53 bit

mantissa, so it is rounded to the next representable value which happens

to be 9223372036854775808 (the next lower representable FP value btw is

9223372036854774784, so subtracting any value <= 512 doesn't have any

effect).

If int(18446744073709551615/2) gives you 9223372036854775807 you

probably have compiled perl to use long double arithmetic.

Funny things can happen like the sign bit is duplicated during arithmatic.

C doesn't define[1] what happens if you right-shift a negative value.

But Perl does, at least if don't "use integer":

| Note that both "<<" and ">>" in Perl are implemented directly using

| "<<" and ">>" in C. If "use integer" (see "Integer Arithmetic") is in

| force then signed C integers are used, else unsigned C integers are

| used.

(perldoc perlop)

So (-1 >> 1) uses unsigned integer operations. (unsigned)-1 is

guaranteed to be the largest unsigned integer, so (-1 >> 1) is half of

that which is half the largest signed integer (unless there are unused

bits in the implementation, which C allows, but that's exceedingly

rare).

hp

[1] Although I think it's implementation-defined, not undefined.