Well it was close. I could use it, but it is a non-core XS module that doesn't really provide much advantage over Math::BigInt. I was more looking for something that would use Math::BigInt if (and only if) it was needed.

So for example, a name I might choose for my module could be "Math::MaybeBig" or "Scalar::Compat64" or something. And, maybe providing 'pack' for old perls doesn't belong in the same module as compatibility shims for modern 32-bit perl?

but it is a non-core XS module that doesn't really provide much advantage over Math::BigInt

Well, Math::Int64 does provide better performance than Math::BigInt.
But if you're looking for something that's already part of perl's core, then I can't think of anything other than Math::BigInt.

I take it you're aware that most 32-bit perls (especially the modern ones) have 64-bit IV/UVs and already support pack's "Q" template.
In any case, you'll also find 32-bit builds whose IV/UVs are only 32-bits ... and I understand these are the builds that you're wanting to cater to.
You distinguish between the 2 different configurations by checking to see whether $Config{ivsize} is 4 or 8. (Sorry ... you probably already know all about that.)

Cheers,
Rob

Yeah, actually the biggest driver for this is cpan testers :-) My error message is "Author is lazy and requires 64-bit perl integers". But there's no way I know to exclude the 32-bit perls, and then I get those pesky failures on my testers matrix. And then I was thinking "Maybe I could try not being lazy and actually make it work on 32-bit perls?"

This is in fact the same reason I fixed ELF::Writer to support 32-bit perls and perls before 5.10, but yes I know I could just declare a minimum perl version and not need to see errors on 5.8 related to pack('Q<'). But I already implemented the workaround for pack('Q<'), so seems a shame to not keep using it.