Unsigned but negative?
PsyenceFact
Junior Member
If anyone can explain the following behaviour I'd be very grateful.
Plain old integers produce the expected result - the type cast results in the decimal value of the two's complement representation of the negative number.
Just wondering if anyone has experienced anything similar, or can explain what's going on.
Andy
stack_var long var_long stack_var slong var_slong var_slong = -1000 var_long = type_cast(var_slong) send_string 0, "'var_slong = ', itoa(var_slong)" send_string 0, "'var_long = ', itoa(var_long)"The code produces this output:
Line 6 (18:34:25):: var_slong = -1000 Line 7 (18:34:25):: var_long = -1000Now forgive me for being picky but isn't one of the points of an unsigned data type that it is, in fact, unsigned? Testing (var_long < 0) gives the expected result of zero, but even so...
Plain old integers produce the expected result - the type cast results in the decimal value of the two's complement representation of the negative number.
Just wondering if anyone has experienced anything similar, or can explain what's going on.
Andy
Comments
-
Welcome to the bizzaro world of Netlinx variables.
-
Oops! Don't do that!
Paul -
I suspect it may just be an issue with the display (although how, I have no idea). I stumbled across this when converting a slong to a 4-byte char array for sending to a piece of equipment. The bitwise operators don't like signed values so I type_cast to long before extracting each byte. It seems to work fine across the required range of input values.
define_function char[4] IntToChar(slong num) { stack_var long cast_num stack_var char obj[4] cast_num = type_cast(num) for (n = 4; n; n--) { obj[n] = type_cast(cast_num >> ((4 - n) * 8)) } return obj }I'll just sweep the minus sign under the NetLinx carpet and move on.
Andy -
There are a fair number of under-the-hood conversions in NetLinx, no doubt from overloaded functions we have no access to. My habit is to be very explicit with type casts and assignments so that every variable is exactly what I expect it to be going in, so there are no surprises coming out.
-
It sounds like you already understand what's happening from your comment about integers working the way you expected. The missing piece here is that ITOA doesn't care what type its argument is, it's casting it to SLONG (see the help file). Whether you call itoa(-1000) or itoa(4294966295) you'll get out -1000 because it's expecting a signed value.
-
Thanks to jweather for sorting out that little mystery. I simply never thought to account for any effect that itoa might have on the values concerned!
Andy -
ATOI is also kind of funny in that it returns 0 if no valid characters are found. But it will also return 0 if you do atoi('0').
Paul
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums