LINE 1: 855638016 == 855638016
LINE 2: 855638016 == 855638016
[download]

LINE 1: 855638016 == 5150605312
LINE 2: 855638016 == 855638016
[download]

"I don't know what "TinyPerl" is

http://tinyperl.sourceforge.net/, I found after this, I'd never heard of it either.

The actual requirements:

• That you 'use integer'
• That the size of your perl's integer is 4 bytes (check perl -V:ivsize) or that you use & 0xFFFF_FFFF.

The actual requirements:
•That you 'use integer'
•That the size of your perl's integer is 4 bytes (check perl -V:ivsize) or that you use & 0xFFFF_FFFF

I think there's at least one more condition, namely: Do not assign a value that's greater than UINT_MAX.

I don't know what others expect to happen when, having chosen to 'use integer', one assigns (to a perl scalar) a value that is greater than UINT_MAX, but the result is one that I do not expect.
This is behaviour that I do expect when ivsize is 4:

C:\> perl -Minteger -wle "$x = 4294967295 + 3;print $x;"
2
[download]

And I expect the same output when I do:

C:\> perl -Minteger -wle "$x = 4294967298;print $x;"
4294967298
[download]

Alas, such handling of this corner case leaves me feeling uneasy about using the integer pragma at all.

How many other surprises (or traps for the unwary) are to be found in the finer details of this pragma's behaviour ?

Cheers,
Rob

& only works on numbers that fit in an IV (a signed integer type) or UV (an unsigned integer type). This range is -2,147,483,648..4,294,967,295 for you. Without use integer;, 872_415_232 + 4_278_190_080 produces a number larger than that, so & produces junk. Specifically, it returns the largest UV (4,294,967,295 for you), which %d casts to an IV (-1).

Got it! Thanks. But you know, in many other programming languages, it doesn't work like that. For example, both JavaScript and Perl use 64-bit IEEE-754 double precision floats for numbers. So, doing the same complex calculation in Perl and JavaScript, one should get the SAME RESULT. That was my assumption. But that's not the reality.

Perl is closer to C than to JavaScript.

$ cat a.c
int main() {
    double x = 1;
    double y = 1;
    int z = x & y;
    return 0;
}

$ gcc -Wall -Wextra -pedantic a.c -o a && a
a.c: In function ‘main’:
a.c:4:15: error: invalid operands to binary & (have ‘double’ and ‘doub
+le’)
     int z = x & y;
               ^
a.c:4:9: warning: unused variable ‘z’ [-Wunused-variable]
     int z = x & y;
         ^
[download]

And the underlying reason for that is that CPUs simply can't perform bitwise-AND on floats (because it makes little sense to do so).

from sprintf :

• %d a signed integer, in decimal .

> This is totally unacceptable!

RTFM? ;-p

update

have no 32 bit but this works for me:

  DB<4> printf "\nLINE 1: 855638016 == %x", (0x34000000 + 0xFF000000) 
+& 0xFFFFFFFF;

LINE 1: 855638016 == 33000000
  DB<5>
[download]

Wait. You mean they magically become integers when they need to. Right? Because, what I've noticed here is that they magically become -1 when Perl runs out of tricks! That is when I put a # in front of the "use integer;" line. Please look at my code below:

use strict;
use warnings;
use integer;

my $string = 'Hello World!';
my $x = Checksum($string);

printf("\n\nChecksum = %0.8X\n", $x);
exit;

#
# This function returns a 32-bit integer.
#
#   Usage: LONG = Checksum(STRING)
#
sub Checksum
{
  my $C = 0x55555555;  # Starting value.

  # Make sure we got a valid string argument.
  @_ or return $C;
  my $S = shift;
  defined $S or return $C;

  # Start the loop with the
  # last character of the string:

  my $i = length($S);
  my $V;
  my $H;
  my $L;
  while ($i--)
  {
    # $V contains the character code shifted
    # to the left by either 0, 8, 16, or 24 bits:

    $V = ((vec($S, $i, 8) + 1) << (($i & 3) << 3));

    # We add this value to the checksum $C
    $C += $V;

    # Then we rotate this 32-bit "checksum" to
    # the left by 1. There is no ROL operator
    # in Perl, so we take the 32nd bit ($H) and
    # then we shift the rest to the left, and
    # finally we OR the low and high bits
    # together to achieve the desired rotation.
    # So, it would look something like this:
    # 01110101011111111101000001110000 <<<
    # 11101010111111111010000011100000 <<<
    # 11010101111111110100000111000001 <<<
    # 10101011111111101000001110000011 <<<
    # 01010111111111010000011100000111 <<<
    # 10101111111110100000111000001110 <<<
    # 01011111111101000001110000011101 <<<
    # 10111111111010000011100000111010 <<<
    # 01111111110100000111000001110101 <<<

    $H = (($C >> 31) & 1);
    $L = (($C << 1) & 0xFFFFFFFE);
    $C = $H | $L;

    # Now, here we print a snapshot of $V
    # and we print the high bit and the low
    # portion of the integer:
    printf("\nV=%0.8X \tH=$H L=%0.32b", $V, $L);
  }

  # Make sure we return a 32-bit integer
  return $C & 0xFFFFFFFF;
}
[download]