Menu
▾
▴
1 Attachments
#215 Compiler errors: casting pointer to 32-bit int
When I built XSB, I got a number of "cast pointer to 32-bit integer" errors. As there's no way to tell GCC to use 64-bit int as the default, I hand-patched these to "long" from "int". However, it would be better to fix this with the appropriate types (perhaps int_fast64_t?) but I don't know the cross-platform style for XSB's source, so I just made it work with GCC -m64 (attachment)
I try to keep MSVC 32-bit and 64-bit happy by adding necessary casts and changing declarations where possible/necessary. The complication is that for MSVC (long long) is 64-bit and in GCC (long) is 64 bit. The typedefs to use are
Integer for 64-bit integer, which is (long long) for MSWIN, and otherwise (long).
So rather than changing int to long if you want it to be 64-bit, change it to Integer.
-David
gcc is complaining about casting a 64-bit pointer to a 32-bit int. I want to run in 64-bit mode, so I must have 64-bit ints, which in gcc is "long" (I can't find any option to tell gcc that "int" is 64-bit -- there is an option for 32-bit pointer, but that's a step backwards).
I suppose the correct solution is to #define a type that's an int of the appropriate size for the pointer size. In the meantime, I can apply these patches, but I have no idea what I'm doing and have to assume that they're doing the right thing.
A few of the patches probably can be rolled into the main source without any fuss because they assign NULL (a pointer) to a pthread_t type (an int).
I don't see where it is a pointer being cast. I see a 64-bit integer cast to an int variable called arity, which can be at most 8-bit, so there doesn't seem a problem to me. Maybe it needs an explicit cast to shut up the compiler. And there are the j's, which are counters. THere may be an issue with hash returning an int, which is 32-bits. That would mean that we can't have hash tables bigger than 4 gig, which some day may be a problem. In XSB C code, we should not use long, since that is ambiguous, as described above. We should use Integer (with the upper case initial letter), if we want (long) in gcc and (long long) in MSVC.
So it seems that Integer is your "correct solution". There is also UInteger (for unsigned) and Float.
I'm attaching the outputs of my compiler. It could be that your code is fine if everything is little-endian (which it is), but I don't know the details of how you're multi-using the pointer/arity/whatever.
When I change from "int" to "long" (as in my diff), the compiler is happy, and the code appears to work (the testall.sh script seems to be happy).
You should change the "int" to "Integer". Then you will get "long" in your compilation, and I'll get "long long" in mine as I need.