# Unsigned int64 wokring wrong

This topic is 1553 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Dear Andreas and all,

1) This code will cause an error "Implicit conversion changed sign of value":

uint64 ui64b = 4294967295;

But this won't:

uint64 ui64b = 4294967296;

2) If I declare a global application function like FnTestUint64(uint64 val) and pass ui64b variable to this function, then there are two different behaviours:

uint64 ui64b = 4294967295; FnTestUint64(ui64b); // C++ debugger will show incorrect value 0xffffffffffffffff

uint64 ui64b = 4294967296; FnTestUint64(ui64b); // C++ debugger will show correct value 0x0000000100000000

0xffffffffffffffff is -1 in int64 and 18446744073709551615 in uint64.

It seems that compiler incorrectly converts 4294967295 to int as -1, then converts this -1 to int64, then converts this big -1 (represented as 0xffffffffffffffff) to uint64

Maybe it is a well-known bug? Is it possible to fix it?

Thank you.

Edited by Apmyp

##### Share on other sites

I assume this is in C++. As far as I know, you must append "ull" to mark it as a unsigned long long int constant, otherwise, it is interpreted as an int. I think your particular compiler makes the assumption that this should be a 64bit value, and will treat it correctly for you. In GCC, you'll get the (in my opinion) correct warning "integer constant is too large for '<type>' type", where in your case, <type> would be int because you're using an int constant with a value outside the range representable by an int.

##### Share on other sites
Ectara, it is not C++ because I am looked to the memory at pointer gived from GetArgAddress (when investigated an original error).. so there is 0xffffffffffffffff in memory prepared by AngelCode engine.

Also, I declared application function as FnTestUint64(asQWORD ui64b) and there is nothing misunderstandable for compiler.

##### Share on other sites

Ah, now I see which subforum this is. My apologies, I came here through the sidebar on the main forum page, which doesn't show the name of the subforum. I just guessed from the mention of the C++ debugger.

##### Share on other sites

Hi Apmyp,

thanks for the bug report. I'll look into this and have it fixed as soon as I can.

Regards,

Andreas

##### Share on other sites

I've fixed this problem in revision 1732.

Thanks,

Andreas

##### Share on other sites

Hello, Andreas.

I've encountered a similar problem with uint64 values. It seems to me that the value 9223372036854775808 is not processed correctly. However, everything is fine with the values 9223372036854775807 and 9223372036854775809. For 9223372036854775808 I just get 0 but according to http://www.angelcode.com/angelscript/sdk/docs/manual/doc_datatypes_primitives.html  type uint64 supports values up to 18,446,744,073,709,551,615

Regards,

AlexeyO

##### Share on other sites

Are you specifically looking for these problems? ;)

I'll investigate it.

##### Share on other sites

I didn't get any problems with the following tests:

r = ExecuteString(engine, "uint64 ui64 = 9223372036854775808; assert( ui64 == 0x8000000000000000 ); ");
if( r != asEXECUTION_FINISHED )
TEST_FAILED;

r = ExecuteString(engine, "int64 i64 = 9223372036854775808; assert( uint64(i64) == 0x8000000000000000 ); ");
if( r != asEXECUTION_FINISHED )
TEST_FAILED;



Can you give an example script where you see the value become 0?

Edited by Andreas Jonsson