# uintN handles signature bit differently for scalars and attributes #2354

Open
opened this issue Oct 9, 2018 · 0 comments

Projects
None yet
2 participants
Contributor

## The Problem

When `uint` type is applied to an attribute it behaves as signed `int` when the highest bit of the value is set. The problem is observed for any kind of operation; i.e. any reading from an attribute produces signed `int`.

## Expected Behavior

Unsigned type must always be used.

## Steps to Reproduce

This sample code demonstrates the issue:

`````` my uint8 \$i;

for ^9 -> \$c {
if \$c == 0 { \$i = 1 }
else { \$i +<= 1 }
say \$c.fmt('%3d'), ": ", \$i.fmt('%010b'), " : ", \$i;
}

"".say;

class Foo {
has uint8 \$!i;

method t {
for ^9 -> \$c {
if \$c == 0 { \$!i = 1 }
else { \$!i +<= 1 }
say \$c.fmt('%3d'), ": ", \$!i.fmt('%010b'), " : ", \$!i;
}
}
}

Foo.new.t;
``````

The could would produce the following output:

``````  0: 0000000001 : 1
1: 0000000010 : 2
2: 0000000100 : 4
3: 0000001000 : 8
4: 0000010000 : 16
5: 0000100000 : 32
6: 0001000000 : 64
7: 0010000000 : 128
8: 0000000000 : 0

0: 0000000001 : 1
1: 0000000010 : 2
2: 0000000100 : 4
3: 0000001000 : 8
4: 0000010000 : 16
5: 0000100000 : 32
6: 0001000000 : 64
7: -010000000 : -128
8: 0000000000 : 0
``````

Where it's clearly visible that the second block generated from attribute values contains negative when 8th bit of `uint8` is set to 1.

Same result was observed for `uint16` and `uint32`.

## Environment

• Operating system: macOS 10.13
• Compiler version (`perl6 -v`): This is Rakudo version 2018.09 built on MoarVM version 2018.09