That would be true if you used signed integers. For unsigned integers, you will be fine. Even if you needed a few more bytes, Perl uses doubles so you can accurately deal with integers of about 56-bits each.

Sounds fair to me, so I tried it - am I correct in using "L" instead of "N" in the unpack?

my @range = map { unpack "L", pack "C4", split /\./ } qw(10.0.0.0 10.1
+.0.0);
print "@range\n"; # the numbers themselves
print $range[1]-$range[0]+1, "\n"; # how many addresses
for ($range[0]..$range[1]) {
  print join(".", unpack "C4", pack "N", $_), "\n";
}
[download]

When i do the above it reverses the input to 0.0.0.10 -> 0.0.1.10 I can fix this up I guess, but why is it doing that?

Am I using the wrong unpack data type?

After some stuffing around I came up with a solution:

The large integers are never a problem until the 'for' loop, so I just used the ACTUAL host count instead of the numbers representing each address, then added the original address representation that was subtracted when it is joined.

I have limited the width of the range regardless because what I am doing with the IPs is fruitless when there are more than 1 million. So BigInt is useless anyway.

my @range = map { unpack "N", pack "C4", split /\./ } $ARGV[0], $ARGV[
+1];
for (0..$range[1]-$range[0]) {
  print join(".", unpack "C4", pack "N", $_+$range[0]), "\n";
}
[download]

I can't fault the code now, does exactly what I want in every case.

Thanks.

Sorry, my previous reply was a bit of a quickie. I did some experiments and wanted to now more explicitly fill in some of the bits that you and I hinted at.

Your original code and my modified version here:

my @range= unpack "N*", pack "C*", split /[. ]+/, "@ARGV";
[download]

The problem comes when you try to do:

$range[0]..$range[1]
[download]

Range iterator outside integer range at ...
[download]

Your solution of using 0..$range[1]-$range[0] is quite good. You could also do:

for(  $_= $range[0];  $_ <= $range[1];  $_++  )
[download]

sub octets2num {
    my $val= 0;
    for(  split /\./, shift(@_)  ) {
        $val= 0x100*$val + $_;
    }
    return $val;
}
sub num2octects {
    my $val= shift(@_);
    my @bytes;
    while(  0 < $val  ) {
        unshift @bytes, $val%0x100;
        $val= int( $val / 0x100 );
    }
    return ! @bytes ? "0" : join ".", @bytes
}
[download]

Update: I couldn't help golfing the first line of code a bit.

Thanks, all is happy now. I left my first line 'ungolfed' as I actually have 7 other unrelated parameters on the command line after the two IPs.

I thought I should answer my original question about BigInt initialisation that was rightfully dispelled.

I was assuming Perl was as strongly typed as Java, and it is done a lot in Java to force data types to an outputable format from default output functions in some of the java system calls.

Java would do something like this to force an integer to a string so it can pass it to initialise a BigInt: $bigint1.new("",$integer); In Perl there is no need, and the best thing is that BigInts can have ordinary arithmetic functions applied to them, most other BigInts I have seen in other languages have their own BigInt arithmetic functions which make life a mind bending hassle  $x=$bigint1.add($x,$y); for example.

So..... my point?

Numbers and strings are interchangeable (as written in many a Perl book) so you can just assign a numeric variable in the place of a string:

use Math::BigInt;

$std1 = 67*34;
$bigint1 = Math::BigInt->new($std1);
print "std: $std1\nbigint: $bigint1\n";
[download]

Just wanted to contribute to the topic as we veered off it :)