Munair wrote: The problem the OP encountered has everything to do with the binary range of a specific architecture. He wondered about the fact that 32bit complements on a 32bit system return true when compared, while the same comparison returns false on a 64 bit system.
Well, obviously it is not binary then. Since binary the values are equal. As soon as the results are different, SOMEWHERE there is a conversion.
Negative and positive values can only be equal (from a binary point of view) when they are complements of the same type, which is what the OP demonstrated in his example.
See above and previous post. Compilers don't compare binaries. They create a tree node for the comparison, and the semantic phase of the compiler will insert needed conversions to make the types match a pair that the compiler has a comparison for.
So it is important to know that the MSB can be bit 15, 31 or 63 depending on architecture. Hence my remark that bit-comparison (not type comparison) can yield different results on different platforms.
A 64-bit system is perfectly capable of doing a strict 32-bit comparison.
In old QuickBASIC complements didn't exist because the compiler threw an exception when trying to: A AS INTEGER = 32768 while other compilers like C and Pascal shifted bits (-32768) without complaint. ;)
(Borland derived) Pascal treats literals differently (usually with high bit numbers) to have an properly scale them back to the type it is assigned to later. The reason is because somewhat modern pascals both support the signed as the unsigned version of the largest integer, putting the literal in the unenviable position of having a range of -2^(x-1) ... (2^x)-1 or 1.5 times the range of an n-bit type.
I agree, promoting the type would solve the problem. But this is up to the programmer who shouldn't expect a 32bit program to run the same on a 64 bit platform with a 64 bit compiler.
A language has rules. I merely pointed out that there are two commonly accepted rules for dealing with this case. And both are fully governed by the type system, and not by 2-complements math or binary representation (*). That only comes into play in implementing
Another way of explaining It is a matter of which sign extension of 32-bit to 64-bit is chosen while loading the values.
(*) as the typed promoted binary representation is obviously different from the original in the case that both are promoted to a larger integer type.