Date: Tue, 19 Feb 2008 15:30:27 +0100 From: "Heiko Wundram (Beenic)" <wundram@beenic.net> To: freebsd-questions@freebsd.org Subject: Re: 32 bit and 64 bit freebsd binary compatiblty Message-ID: <200802191530.28256.wundram@beenic.net> In-Reply-To: <20080219150754.M3580@wojtek.tensor.gdynia.pl> References: <1563a4fd0802180712w476125a4x229cc38509016b94@mail.gmail.com> <1563a4fd0802190557l46bd6984x29e8f04b1ceed311@mail.gmail.com> <20080219150754.M3580@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Dienstag, 19. Februar 2008 15:08:12 schrieb Wojciech Puchar: > > Can anyone tell how do we handle this situation??? > > > > Is there any way or i have to compile my code on 64 bit machine?? > > what's a problem to compile on 64-bit machine? Ugh, there can be lots of problems, at least if the original programmers weren't careful enough to avoid the many pitfalls of "inter-architecture" development. For example, in C, the long type is 32-bits wide on i386, and 64-bits wide on amd64, whereas int is 32-bits wide on both. Take the following code: #include <stdio.h> int main(int argc, char** argv) { int x; unsigned long y = (unsigned long)&x; printf("%x\n",y); return 0; } The formatting code "%x" expects an unsigned integer, but is given an unsigned long (which is always big enough to fit an address, that's mandated by the C standard, and so will contain the memory address of x). gcc only warns about the non-matching format-string argument when run with -Wall. On i386, this doesn't matter, as sizeof(int)==sizeof(long). On amd64, this does matter, as printing a %x will only print the low-order four bytes of the memory address, and not the upper four bytes, so that the output string will no longer be unique for object x, depending on how the virtual memory space is partitioned. Now, I've seen quite a good deal of software who do stuff similar to this (at least in spirit, by casting an address to an unsigned integer) to build (hash) tables, and they all miserably fail when compiled on amd64, simply because they presume that sizeof(int) == sizeof(long), which isn't true on amd64 anymore. If the OP's development team haven't taken care to avoid these pitfalls from the start (which I guess they didn't, simply because they are only used to developing on i386), they can be in for a real treat when trying to compile _and run_ their application on amd64. I know I've had my fair share of (re-)learning to do when initially compiling my (personal use) C++ programs on amd64. -- Heiko Wundram Product & Application Development
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802191530.28256.wundram>