# Problem with binary numbers

#### Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

•  Subject
• Author
• Posted on
A third-party module that I'm using has a couple of binary constants defined:

GENERIC_READ=10000000000000000000000000000000
GENERIC_EXECUTE=100000000000000000000000000000

The binary value for GENERIC_READ|GENERIC_EXECUTE would be:
10100000000000000000000000000000

I'm trying to check if a field in an object created by the module equals
GENERIC_READ|GENERIC_EXECUTE, but I'm running into a problem.  If I print out
the value for a field that I know equals GENERIC_READ|GENERIC_EXECUTE, then it
prints out -1610612736.
But when I have the statement "print GENERIC_READ|GENERIC_EXECUTE", it prints
out 2684354560.

The following statements both print out 10100000000000000000000000000000:
printf("%0b\n", 2684354560);
printf("%0b\n", -1610612736);

So the binary representation for GENERIC_READ|GENERIC_EXECUTE has 2 different
decimal representations, a positive one and a negative one.  Why does the
field in the object created by the third-party module have a negative decimal
representation, while my own code has a positive decimal representation?

## Re: Problem with binary numbers

> A third-party module that I'm using has a couple of binary constants defined:
>
> GENERIC_READ=10000000000000000000000000000000
> GENERIC_EXECUTE=100000000000000000000000000000
>
> The binary value for GENERIC_READ|GENERIC_EXECUTE would be:
> 10100000000000000000000000000000
>
> I'm trying to check if a field in an object created by the module equals
> GENERIC_READ|GENERIC_EXECUTE, but I'm running into a problem.  If I print out
> the value for a field that I know equals GENERIC_READ|GENERIC_EXECUTE, then it
> prints out -1610612736.
> But when I have the statement "print GENERIC_READ|GENERIC_EXECUTE", it prints
> out 2684354560.
>
> The following statements both print out 10100000000000000000000000000000:
> printf("%0b\n", 2684354560);
> printf("%0b\n", -1610612736);
>
> So the binary representation for GENERIC_READ|GENERIC_EXECUTE has 2 different
> decimal representations, a positive one and a negative one.

Put it the other way round:  The bit pattern has two different numeric
interpretations -- one as an unsigned integer and one as a signed integer.
Perl integers contain a flag that says which interpretation is valid.
To see the difference:

use Devel::Peek;
Dump 2684354560;
Dump -1610612736;

> Why does the
> field in the object created by the third-party module have a negative decimal
> representation, while my own code has a positive decimal representation?

All you told us about the module is that it is "third party", so how can
you expect anyone to answer a question about it?  It may be a bug in the
module or it may be deliberate, who knows.

If you use the numbers as masks to test against flags like GENERIC_READ
etc, the difference doesn't matter.  If you must compare them for equality,
you can use sprintf( "%u", \$x) == sprintf( "%u", \$y).

Anno