Re: Trying to use gdb on OS X
- Posted by jimcbrown (admin) Jun 09, 2013
- 3328 views
Okay, I'll undo my code and try to add a #ifdef EOSX to the existing #ifdef ARM or something and try that.
Well, we know that your code works. Maybe the right thing to do is to add your code around an #ifdef EOSX.
Well, the better goal would be to make something that is completely portable without an #ifdef if possible.
Well, speed is an issue here. Doing these casts unnecessarily on x86 might slow it down (but then gain it might not).
Second would probably be to define a macro that converts dbl to int reliably and wrap that in #ifdef if necessary.
I can't see a downside to that.
Wait a minute -- can't we cast to long and then to unsigned long? It's the cast of (-1) to unsigned long which is implementation defined right?
Idea which might be portable: in Dand_bits, cast to long, then in and_bits cast to unsigned long.
Perhaps, but so is any bitwise operation involving more than 32bits according to the other thread.
Right, I meant to include all of the D*_bits() functions.
Unfortunately, casting to long first still doesn't work because I can't get just the bits of 0xDEADBEE5 from the double into a 32-bit number. It works for 0xFFFFFFFF. I have to cast to long long and then to unsigned long.
Ouch.
Can we guarantee that long long is 64 bits on all platforms, or use int64_t or something? If so, then I think that's a good portable solution which could fix ARM and OSX and still work on Windows/Linux because conversion from long long to unsigned long is defined to work properly.
Regardless, I'll continue testing.
I'd say we should use int64_t, as that's standardized, while 'long long' is really a GNU extension.
Thankfully we no longer have to worry about Watcom. (IIRC it doesn't support either, we'd have to use __int64 or something there if we needed a 64bit integer type for some reason.)
