Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I know to check for/use asserts and carefully examine any assembly components, but I didn't know if anyone out there has a fairly comprehensive or industry standard check-list of specific things at which to look? I am looking more at C and C++.

note: There are some really helpful answers, I'm just leaving the question open for a couple days in case some folks only check questions that don't have accepted answers.

share|improve this question
    
Microsoft has quite a good documentation about Programming Guide for 64-bit Windows –  Giorgi Jan 31 '11 at 19:15

4 Answers 4

up vote 7 down vote accepted

Not a comprehensive list, but some of the things I ran into when converting a large C++ codebase:

Libraries, of course. Find all of them, and see what they've got. In my case, we decided to move to Open Source libraries for JPEG handling and data compression, and so we compile our own. Commercial libraries may give you more problems.

Pointer conversions. On 32-bit systems, usually sizeof(int) == sizeof(void *), and lots of people work on that basis. On a 64-bit system a round trip from pointer to int to pointer will frequently lose half the pointer. Your compiler should be able to help here.

Data object size values. This would be a good time to go through and change all size values to size_t, if you can find them, and pointer differences to ptrdiff_t. This isn't necessarily going to be a problem, but since we were being pushed by the size of the data we were working on I wanted to make sure it could grow as much as possible.

Object size. Any struct or class you've got with pointer members is going to grow, and if you're changing any int to size_t or ptrdiff_t. Again, this is unlikely to be a problem, but you may want to check for I/O. If you're doing any binary I/O, you really need to examine what's being input and output. If you're sending or receiving data through a fixed protocol, you need to look at it. Do a grep for union and check each one for changes.

share|improve this answer

One thing to be careful with is third-party libraries you depend on. Some may not have been ported to x64 or have a separate version for x86 and x64 projects, so you will have to do some extra work to manage dependencies and make sure you're building against the correct library for your target platform.


Do you have any thoughts on moving depended packages into the source tree to minimise this type of problem? For example, mplayer does this. I have noticed doing it this way often mangles some things and leads to a complicated configure script, but it seems like a valid approach.

That sounds fine to me, especially if you can automate most of not all of your dependency management for builds.

Last time I ran into this, we did something like this: we kept third-party dependencies on a share (and/or source control -- we tried both ways) and developers maintained their local environment using provided batch scripts to set it up with the right versions. The code would be written with a reference to a particular DLL name in mind. We worked in .NET, so for example our project files would reference Whatever.dll and when the build was done, we had a script that'd sub the 64-bit version in its place. If I recall, the build machine would use the same scripts the devs would use to grab the right library versions. Project files didn't need to be changed, since dll names didn't change.

Where I'm at now, we edit csproj files to include platform-specific references, so instead of the normal relative path to the dependency that Visual Studio inserts, we use the ${Platform} variable and it's controlled through project configurations -- in an x64 project, we'll have a "win64" configuration, so ${Platform} will be replaced with "win64" and the dlls would then be pulled from the "win64" subfolder of the folder that contains all our dependencies.

share|improve this answer
    
@aking1012 I updated my answer. Hope that helps. –  Anna Lear Jan 31 '11 at 18:06
    
Thanks again, definitely helpful. –  hbdgaf Jan 31 '11 at 18:13

For pure Java programs, there are none.

share|improve this answer
    
I understand the benefits of using VM based/interpreter based languages, thanks. I actually prefer to use ruby for the meat and rails for the UI on that type of task, but I was more looking at some existing linux packages that were written in C/C++ and haven't been updated in a while/migrated to x64. If I'm going to pitch in, I don't want to do a poor job. –  hbdgaf Jan 31 '11 at 17:03
5  
Perhaps you should update your question with a note on that the platform is Linux and the language is C/C++. The better the question, the better the answers. –  user1249 Jan 31 '11 at 17:28
1  
added a C tag to the question to address the ambiguity. i think the answers could be equally valid for linux/unix/windows. i was trying to not have developers for a differing OS but similar problem to be dismissive of the question due to containing the word linux. thx for the input –  hbdgaf Jan 31 '11 at 17:33

Testing is one of the most important things to consider. Most software testing is based on "grandfathering" - functionality that used to work and has not changed will be OK for this release. What you will find with moving to 64 bit (unless your code is particularly good) is issues that have not had symptoms previously will come up - sometimes in weird and unexplained ways. Things like buffer overflows previously "contained", assumptions about data sizes causing new buffer overflows, dodgy pointer math etc.

The amount will largely depend on the quality of the code base - in one case it took a very long time to get from "finished" to "customer acceptance".

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.