Unsigned int64 wokring wrong

Started by
7 comments, last by WitchLord 10 years, 5 months ago

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.

Advertisement

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.

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.

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.

Hi Apmyp,

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

Regards,

Andreas

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

I've fixed this problem in revision 1732.

Thanks,

Andreas

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

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

Are you specifically looking for these problems? ;)

I'll investigate it.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

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?

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

This topic is closed to new replies.

Advertisement