> Benoît Minisini ha scritto:
> >> It seems that there are bugs in the "Ror" function too.
> >> Using the same number, 197 (11000101), if I write ROR(197,3) I get
> >> -1610612712 (
> >> 10111000)
> >> instead of 10111000 (184).
> >
> > 197 is
Benoît Minisini ha scritto:
>> It seems that there are bugs in the "Ror" function too.
>> Using the same number, 197 (11000101), if I write ROR(197,3) I get
>> -1610612712 (
>> 10111000)
>> instead of 10111000 (184).
>
> 197 is not a Byte, it
> It seems that there are bugs in the "Ror" function too.
> Using the same number, 197 (11000101), if I write ROR(197,3) I get
> -1610612712 (
> 10111000)
> instead of 10111000 (184).
197 is not a Byte, it is an Integer. If you want a Byte, y
It seems that there are bugs in the "Ror" function too.
Using the same number, 197 (11000101), if I write ROR(197,3) I get
-1610612712 (
10111000)
instead of 10111000 (184).
--
Leonardo Miliani
Web: www.leonardomiliani.com
E-mail: leona...@
I made some tests on bit manipulation functions and I think I've found some
bugs in them (Gambas 2.12.0).
I read in the documentation that a function like SHL should keep care of
the initial type of data.
I.e., if I use a byte, it should work using 8 bits (the lenght of a byte),
if I use an intege
I made some tests on bit manipulation functions and I think I've found some
bugs in them (Gambas 2.12.0).
I read in the documentation that a function like SHL should keep care of
the initial type of data.
I.e., if I use a byte, it should work using 8 bits (the lenght of a byte),
if I use an intege
