Quote:
Originally Posted by T74marcell
You can certainly run 32-bit applications on a 64-bit machine, but you have to be aware that in some cases the results can be different when compared with the results from a 32-bit architecture.
If the application does some bit masking operations or does some comparison with hexadecimal values, then you have to make sure that 'long long' values are used, and you also have to take care about signed and unsigned values.
|
I think you're either answering the wrong meaning of the question, or seriously confused.
I think the OP's question was about running software compiled for x86 32-bit under an x86-64 kernel. That is relatively problem free, and none of the issues you discussed apply.
You seem to be discussing what happens when code was written with the assumption that it will be compiled in 32-bit mode, but that code is compiled unchanged in 64-bit mode.
Such source code is fairly rare in open source, because people tend to notice the lack of portability.
Quote:
assuming that 'long myValue = 0x7FFFFFFF;'
on a 32-bit system 'myValue == 0x7FFFFFFF' is true,
on a 64-bit system 'myValue == 0x7FFFFFFF' is NOT true, because myValue is actually 0xFFFFFFFF7FFFFFFF (it's 64-bit), and
0xFFFFFFFF7FFFFFFF != 0x7FFFFFFF
|
That is wrong in so many ways, I can hardly list them. Some are:
If you set 'long myValue = 0x7FFFFFFF;' then most certainly 'myValue == 0x7FFFFFFF' is true. The is true when compiled 32-bit (whether run on a 32 bit or 64 bit system) and true when compiled 64-bit.
Sign extension can occur on some values, but the same interpretation would occur both times you use the same constant.
Anyway, 0x7FFFFFFF is positive, so it does not sign extend to 0xFFFFFFFF7FFFFFFF.
Someone coding for 32 bit mode would tend to use 'long' only if they are trying to be portable to other sizes of int or long. So they probably thought about such issues. It is easy to construct intentional portability flaws around the fact that long is 32 bits in x86, but 64 bits in x86-64 (though you missed) but such flaws are rare in real code.
When you see mixtures of std::size_t with int or unsigned int, then you should really worry about whether the author thought through the portability issues to an architecture where std::size_t is larger than unsigned int. std::size_t is often used just for type compatibility with standard functions that expect or return it, so its use does not imply the author has thought through the consequences of the fact that std::size_t is big enough to hold the difference between pointers and int might not be.
