Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Issues with porting C++ code to a 64-bit platform

viva64.com

Post reply on HN
Print view View original

1–10 of 45 posts

Re: Issues with porting C++ code to a 64-bit platform

#3

Post by mpyne »

I had issue #2 (varags) bite me once on a C function where a NULL pointer was used as a sentinel.

In C++ we normally use '0' as the name of the null pointer, as C's NULL macro ((void*)0) gives compilation errors normally (though it would have worked here). And of course, who knows what the NULL macro is defined to in C++ mode, it could be plain '0' or a compiler-specific type.

With varargs '0' simply translates to int 0. That is, 32-bit int 0, whereas the function was expecting a 64-bit null pointer. So on 32-bit mode it happened to work fine, but crashed when compiled for 64-bit platforms.

Re: Issues with porting C++ code to a 64-bit platform

#5

Post by georgemcbay »

This is great information for anyone making the 32-bit to 64-bit transition, and at this point you really should be viewing 64-bit as your primary platform if you're writing code for x86(amd64) platforms. Just falling back to 32-bit mode with WoW or similar for your target platform is just inexcusable at this point unless you have very specific legacy support issues.

As someone who has been stepping away from C/C++ code towards Go, I'll add this for anyone in a similar boat:

When interfacing C (via CGO) or C++ (via SWIG) code with Go code the #1 thing to keep in mind with 64-bitness is that int in Go may be either 32-bit or 64-bit depending upon the GOARCH the compiler is targeting. int on the C/C++ side is virtually always 32-bit, even on a 64-bit compiler. Use int32 on the Go side to match int on the C/C++ side if you need your structs to align correctly when passing data back and forth.

Re: Issues with porting C++ code to a 64-bit platform

#6

Post by ChuckMcM »

bitwize wrote: post #4
ChuckMcM wrote: post #2

Good things to keep in mind. Especially for a generation of programmers who didn't go through the 16 bit -> 32 bit transition. (Trust me, you do not want to write C code on an 80286)

holy shit far pointers I just flashed back, man

Don't worry its just PSASS [1]

[1] Post Segmented Architecture Stress Syndrome

Re: Issues with porting C++ code to a 64-bit platform

#8

Post by Keyframe »

bitwize wrote: post #4
ChuckMcM wrote: post #2

Good things to keep in mind. Especially for a generation of programmers who didn't go through the 16 bit -> 32 bit transition. (Trust me, you do not want to write C code on an 80286)

holy shit far pointers I just flashed back, man

and DOS Extenders, namely DOS/4G(W).

Re: Issues with porting C++ code to a 64-bit platform

#9

Post by jws »

mpyne wrote: post #3

I had issue #2 (varags) bite me once on a C function where a NULL pointer was used as a sentinel. In C++ we normally use '0' as the name of the null pointer, as C's NULL macro ((void*)0) gives compilation errors normally (though it would have worked here). And of course, who knows what the NULL macro is defined to in C++ mode, it could be plain '0' or a compiler-specific type. With varargs '0' simply translates to in…

Heh. Sometime around '94 I helped Southwestern Bell Telephone with that during the 16 bit to 32 bit transitions of a Mac client.

This means that sometime around the mid 2030's some poor programmers will have to take a break from worrying about Y0x80000000 to get bit by the x86-128 varargs bugs.

Re: Issues with porting C++ code to a 64-bit platform

#10

Post by 16s »

But while trying to store a 64-bit integer in double the exact value can be lost (see picture 1).

I've seen that first hand. In fact, I wrote code to fix it. The guy who wrote the code, still did not get it... 64 bits is 64 bits he said, right... well yes, but that's not the issue here. When you have an int that is say 56 bits in size and you put it in a double that is 64 bits... see what happens:

#include

#include

int main()

{

    boost::uint64_t too_big = 72057594037927936;

    double wont_fit = too_big;

    std::cout
}

./a.out

72057594037927936

7.20576e+16

The maddening part about this is that it's hit or miss. Smaller numbers fit just fine:

#include

#include

int main()

{

    boost::uint64_t not_too_big = 281234;

    double will_fit = not_too_big;

    std::cout
}

./a.out

281234

281234

Finding and fixing bugs like this will cause ulcers.

Post reply on HN