I looked at the 'D' format, and it would work on machines that have 64bit integer hardware, but I need to support some 32 bit only machines. But you got me thinking, and I used some basic math to get what I need (I hope?).

The following code seems to do what I need:

   use strict;
   use warnings;
   
   my $num4g = 2 ** 32; my $grt4g = 500_000 + $num4g ;
   my $start = $num4g - 50; my $no = 0;
   while ( 1 )
   {  my $no1 = Pack( $start );
      my $result = UnPack( "$no1" );
      if ( $start != $result ) { die "not match"; }
      $start++; $no++;
      if ( $start >= $grt4g ) { print "Okay ( $no )\n"; exit; }
   }
   
   sub Pack
   {  my $input = shift;
      my $lower = $input % $num4g;
      my $upper = int ( $input / $num4g );
      return ( pack("N N", $upper, $lower ) );
   }
   
   sub UnPack
   {  my $input = shift;
      my ( $upper, $lower ) = unpack("N N", $input);
      return ( ( $upper * $num4g ) + $lower );
   }
   
   
   1;
[download]

Do you see anything wrong with the code?

Thank you

I looked at the 'D' format, and it would work on machines that have 64bit integer hardware, but I need to support some 32 bit only machines.

First, an apology. When I said 'D' template above, I meant 'd'. (I often mix these up as so many of the other lower/upper case pairings, n is the smaller and N is the larger. But for floating point it is 'f' for the smaller and 'd' for the larger. With 'D' being a later addition that is larger still but not supported on 32- bit).

By using 'd' as your template, you can portably (with restrictions) pack and unpack 'integers' upto 2**52 across the 32-bit/64-bit divide:

\perl32\bin\perl -e"$n=2;$n*=2 for 1..52;$n-=20;print pack'd',$n++ for
+ 1..20" | 
perl -nE"printf qq[%16.f\n],$_ for unpack'd*', $_"
9007199254740972
9007199254740973
9007199254740974
9007199254740975
9007199254740976
9007199254740977
9007199254740978
9007199254740979
9007199254740980
9007199254740981
9007199254740982
9007199254740983
9007199254740984
9007199254740985
9007199254740986
9007199254740987
9007199254740988
9007199254740989
9007199254740990
9007199254740991
[download]

Thus avoiding the need to do custom packing.

Do you see anything wrong with the code?

No. The logic seems fine to me. If you decided to use this in preference to 'd', and will be un/packing long strings of values, then you might want to modify your routines to process variable numbers of values (ie. do the equivalent of 'Q*'), for efficiency.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

I tried the 'd' on both a 32bit and 64bit machine and it works great. However, when you print to disk, you find that the result is not network neutral.

Big-endian order on disk:     decimal 4294967246  hex'41EFFFFFF9C00000
+'
Little-endian order on disk:  decimal 4294967246  hex'0000C2F9FFFFEF41
+'
[download]

Note: I hope I typed the numbers correctly, since I can't cut/paste from my aixterm window to the web page. I have to save as a dos format file and then use notepad to view the file and then cut/paste. A lot of work for 2 lines :-)

But let's hope the 'D' is improved to work on 32/64bit and is also network neutral. It would be the perfect answer.

Thank you

"Well done is better than well said." - Benjamin Franklin

Thanks, I look into that!