Within Math::Int64 look at https://metacpan.org/release/SALVA/Math-Int64-0.54/source/Makefile.PL#L46 and https://metacpan.org/release/SALVA/Math-Int64-0.54/source/Makefile.PL#L111.

if($Config::Config{ivsize} < 8) {
  print "Bailing out - 64-bit integers (IV) are required\n";
  exit 0;
}
[download]

With Config.pm you could check for d_quad. Another funny way to find the internal integer size is

perl -E 'say unpack "%b*", pack "j", -1'
[download]

similar idea, slightly shorter :)

  DB<10> p length sprintf '%b',-1
64
[download]

but reliability may be effected by various math pragmas ...

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

... bail out if there is not support for 64 bit but then I'll get spammed by CPAN testers running tests on 32-bit Perls. Is there any way to avoid this?

cpantesters will treat a report that dies/exits with "OS unsupported" in the message as an NA result (which will not show up as a FAIL, and I don't think gets spammed to you; I've never gotten a mail for NA, that I remember, anyway). More about NA can be found in the CPAN Tester Wiki "Reports" section; it doesn't specifically mention the required die-message, but my tests show that any message starting with "OS unsupported" -- and it might be "containing" rather than "starting with" -- will trigger the NA.

With ExtUtils::MakeMaker, running os_unsupported() from the Makefile.PL will cause the process to die with the message "OS unsupported". So if you check bitness in Makefile.PL, then run os_unsupported() if not $bit64; or similar message, it will return a cpantesters status of NA. Other build environments may have a similarly-encapsulated function, or you can just die "OS unsupported because of 32bit integers";

Instead of exiting Makefile.PL prematurely, you could replicate what I use in Win32::Mechanize::NotepadPlusPlus 00-load.t, where in the test file, I BAIL_OUT with a $reason message that contains "OS unsupported" (like BAIL_OUT('OS unsupported because of 32bit integers'); for your case). I successfully use that mechanism, as seen in reports like this one to get a result of NA in the matrix. So you could test your bitness in the first .t file run, and BAIL_OUT with an appropriate message if it's not 64bit.

There are many ways to look at the size of integers :)

If you *also* want to support 64bit ints on a 32bit conf, you could consider if Math::BigInt could help

You did not state if your realm is pure-perl or also XS. If you know how to work around your problem in XS, you could pass the big ints as string and work from there.

In the pure-perl world, an "integer" is an IV (Integer Value). Its size in bytes is shown in $Config{ivsize}. Internally an IV does not need to be mapped to an int, but it might be a long or even long long.

$ perl -V:.*64bit.*
use64bitall='define';
use64bitint='define';

$ perl -V:.*size.*
charsize='1';
d_chsize='undef';
d_malloc_good_size='undef';
d_malloc_size='undef';
doublesize='8';
fpossize='16';
gidsize='4';
i16size='2';
i32size='4';
i64size='8';
i8size='1';
intsize='4';
ivsize='8';
longdblsize='16';
longlongsize='8';
longsize='8';
lseeksize='8';
nvsize='16';
ptrsize='8';
shortsize='2';
sig_size='68';
sizesize='8';
sizetype='size_t';
socksizetype='socklen_t';
ssizetype='ssize_t';
st_ino_size='8';
u16size='2';
u32size='4';
u64size='8';
u8size='1';
uidsize='4';
uvsize='8';
[download]

Internally an IV does not need to be mapped to an int, but it might be a long or even long long

Indeed. I'd go further and speculate that an IV is mapped to a long or long long on almost all 64-bit platforms because the two overwhelmingly dominant 64-bit programming models (LP64 and LLP64) both use 32-bit ints. That is, I'd expect to see:

intsize='4';
ivsize='8';
[download]

on just about every 64-bit Perl.

I remember this from a fascinating thread a few months back, where syphilis noted he's "never struck a perl where $Config{intsize} != 4".

If you need integers in the computer sense (IV/UV),

length(pack('J', 0)) >= 8
[download]

or

use Config qw( %Config );

$Config{uvsize} >= 8
[download]

uvsize refers to the size in bytes of such integers.

You need this if you use any of the following:

• the numbers as operands to bitwise operators
• the numbers as operands to `..`/`...`
• pack 'Q'/unpack 'Q'
• hex literals larger than 0xFFFF_FFFF

If you need integers in the mathematical sense, floats (NV) with at least 64 bits of precision would also do.

use Config qw( %Config );

$Config{uvsize} >= 8 ||
   eval($Config{nv_overflows_integers_at}) >= 2**64
[download]

Every integer up and including eval($Config{nv_overflows_integers_at}) can be represented exactly as an NV.

Unless you've done something something, though, this is unlikely to get you more than 53-bits of precision.