NVX wrote:Notice on Linux x64 that sizeof(unsigned long) == sizeof(size_t) == sizeof(void*), and the same on Windows x86, but on Windows x64 unsigned long is still 32bit.
Yes, these are the ILP32, LLP64 and LP64 data models, respectively. See e.g.
for additional information.
As such, the Windows x64 build would probably break a lot of code which assumes that unsigned long == sizeof(void*).
Yes, indeed. However while I'm in hindsight somewhat unhappy about the rather extensive use of unsigned long
s in the Cafu code (big parts of which were written before 64-bit systems became a conscious factor), I don't think that that now is a big problem:
- Assumptions like sizeof(unsigned long) == sizeof(void*) should be very rare in all Cafu code, and
- the Linux LP64 code already compiles and works very reliably (which of course doesn't mean that no more bugs are in it).
In summary I'm quite confident that the port to LLP64 is feasible with reasonable or even little effort.
Also, I've noticed some code that assumes an unsigned long is always 32bit (which, would ironically break Linux x64 runtime, but otherwise build fine, if you're very unlucky)
For example in the same Network.hpp file
Code: Select all
/// Writes one LongWord (32 Bit) into the data buffer.
/// @param l LongWord to write.
void WriteLong(unsigned long l)
Perhaps some uint32 uint64 etc types are called for to be unambiguous.
Ahhh, you've identified one of the few (at least according to my still unverified claim...) spots that are problematic. You're right regarding the solution as well: uint32
and similar types should rather be used here.
If you'd like I can give you access to a Windows x64 Virtual Machine with Visual Studio installed for development purposes
Wow, that would be very kind of you
- how exactly would I be able to access that VM?
I'm guessing that a lot of code would need to be touched in order to fix x64 properly
Yes, ripple effects from changing to types like uint32
can indeed imply plenty of edits...