The perlop documentation shmem brought to my attention gives a formula for a big integer value but also mentions that most arithmetic is carried out in floating-point by default. The integer pragma can change that but will also have consequences for signed/unsigned, division and modulus semantics.

jwkrahn demonstrated that the POSIX module provides an own set of various numerical limits. I guess, however, that those apply to this particular interface rather than to perl internals.

Finally, BrowserUk suggested exploiting floating-point precision on 32-bit machines and gave a code snippet probing for the precision actually available.

One question that has not been answered yet is whether 31 bit for positive values was as bad as it can get. I have found no counter-examples so far.

In short, there are more factors determining whether an arithmetic result can be expected to be precise than a simple size check. I'll have to look more closely into automatic numerical type conversion and how perl handles individual operators.

For example, on a machine with less precision in floats than in integers (a 64-bit machine with IEEE doubles, say), downgrading integer to floating-point should be avoided just like downgrading fp to 32-bit integer on other machines.

But this may be hard to accomplish if the underlying model suggests that integers are considered a subset of floats. I have already found a perl that will do bit-operations in 64-bit unsigned integer but numerical comparison in 53-bit signed floating-point or something, which means that you can have numerically equal values that are different bit-wise (example: 1<<60|1 versus 1<<60).

I'll post a meditation with my findings when I'm done.