ansaurus

Question

Answer 1

+1 A:

First off, why would there be 'porting'?

Consider that most distros have merrily provided 32 and 64 bit variants for well over a decade. So unless you programmed in truly unportable manner (and you almost have to try) you should be fine.

Dirk Eddelbuettel 2010-08-24 15:07:03

what about run-time errors ? do you absolutely trust compiler warnnings for this issue ? i doubt it.

_Avishay_ 2010-08-24 15:12:09

It's too easy to fall into the non-portable trap, even simple stuff like sprintf("%u",sizeof something); will bite you, In my experience , large scale apps have been often been developed over decade, with too many people messing around, and you'll never know what'll explode when you compile/run it on something else than it has ever run

nos 2010-08-24 15:14:28

Ah, programming in a truly unportable manner, that's easy... casting pointers to `int`, having implicit integer propagation when using `va_arg` functions, having seemingly constants change their signedness... don't worry.

Jens Gustedt 2010-08-24 15:16:30

what you guys says actually emphasize that re-compiling for 64 bits is just not enough....

_Avishay_ 2010-08-24 15:30:49

Why don't you actually try it?

Dirk Eddelbuettel 2010-08-24 16:06:58

ofcourse i will, i will also regard to warnnings of compilers, what i'm searching if there is any TOOL that can asist of finding not fixing finding suspicous places to be fixed.

_Avishay_ 2010-08-25 07:41:17

Answer 2

+1 A:

What about compiling the project in 64 bits OS? gcc compiler looks like such tool :)

Alex Farber 2010-08-24 15:07:48

do you know that not every application can be ported to 64 bits with just re-compiling ? do you know there are allot of issues that can cause problems in run-time and not in compile time ??

_Avishay_ 2010-08-24 15:11:09

Agree, but the first step to do is still to compile... Most of incorrect stuff is not compiled, like assigning a pointers to 32-bit integer values, or different int and size_t size.

Alex Farber 2010-08-24 15:22:21

and crank up the warning level: `-pedantic -Wall -Wextra` is a good start. It'll *help* you find some issues. Of course, there is no tool that I know of that will correct your assumptions of certain data types, alignment, assembly and whatnot. That's just to complicated.

rubenvb 2010-08-24 16:41:24

Answer 3

+3 A:

Here's a guide. Another one

Size of some data types are different in 32-bit and 64-bit OS, so check for place where the code is assuming the size of data types. eg If you were casting a pointer to an int, that won't work in 64bit. This should fix most of the issues.

If your app uses third-party libraries, make sure those work in 64-bit too.

David 2010-08-24 15:20:47

i'm familiar with these guides, but the question is , if there is any tool which can save human work hours and is it suffice ? instead of search for thousands of suspicious places in code ....

_Avishay_ 2010-08-24 15:29:16

Answer 4

+3 A:

A good tool is called grep ;-) do

grep -nH -e '\<int\>\|\<short\>\|\<long\>' *

and replace all bare uses of these basic integer types by the proper one:

array indices should be size_t
pointer casts should be uintptr_t
pointer differences should be prtdiff_t
types with an assumption of width N should be uintN_t

and so on, I probably forgot some. Then gcc with all warnings on will tell you. You could also use clang as a compiler it gives even more diagnostics.

Jens Gustedt 2010-08-24 15:25:51

that maybe good , but i'm not sure it covers all pitfalls.... im searching for a tool which covers all pitfalls in order to reduce run-time errors ....<also consider that this grep will produce thousands of results in a large scale app ....making it very hard to follow>

_Avishay_ 2010-08-24 15:31:56

@_Avishay_: sure there are others, but I really think that these are the main ones, generally implicit integer promotions are the rest of it. Also sure, if the code is badly written, this will give you tons of results, but each pointing to a potential trouble spot. You wouldn't be safe if you'd not resolve them all in any case. And also sure that this will be hard to guess sometimes, since using just `int` for example simply lacks the semantic tags any automatic tool would need... I personally don't believe in the existence of tools that transform bad code into good one.

Jens Gustedt 2010-08-24 15:48:30

i'm not searching for a tool to transfer it from unportable code to portable code , thats quite hard for a auto tool , but it seems its easier for a tool to search for unportable places in code that maybe compiler wanning will not find....

_Avishay_ 2010-08-25 07:42:32

@_Avishay_: I don't agree. Asking to port from 32 bit to 64 bit, is in much respect the same as asking to transfer unportable code to portable. The `grep` that I gave gives you a lot of trouble spots for that. For the rest, e.g explicit casts or integer promotions, they are part of the language, and no tool will be able to tell whether or not they are intentional or not.

Jens Gustedt 2010-08-25 09:33:45

what about static code analysis tool ?

_Avishay_ 2010-08-25 12:07:49

Answer 5

+1 A:

I invite you to site www.viva64.com. This site is devoted for C/C++ developers of 64-bit applications. Write to support.

Andrey Karpov 2010-08-31 12:14:41

sounds great is this tool running on Linux as well ?

_Avishay_ 2010-09-04 06:42:02

No. But: 1) It is possible to start in Windows environment in for check Linux of projects. We can port Viva64 to Linux. I can tell about all it in personal correspondence more in detail. My E-mail: karpov|@|viva64.com.

Andrey Karpov 2010-09-05 06:05:03

possible to start in windows environment ? did you check Linux project in visual studio by now ?

_Avishay_ 2010-09-09 16:33:08

See blog post: Testing of Linux-applications with the help of PVS-Studio in Windows - http://www.viva64.com/blog/en/2009/08/06/168/

Andrey Karpov 2010-09-11 11:20:53

ansaurus

tags:

views:

answers:

porting linux 32 bit app to 64 bit ?

related questions