To get a trial key
fill out the form below
Team License (standard version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Request our prices
New License
License Renewal
--Select currency--
USD
EUR
GBP
RUB
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

** This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
How to estimate the process of 64-bit m…

How to estimate the process of 64-bit migration of C/C++ applications?

Sep 21 2009

The article is devoted to the issue of estimating complexity and cost of migration of applications to 64-bit platforms. Such aspects as availability of various components of an application, libraries and development tools are considered. An example of using PVS-Studio program tool for estimating migration is given. Although the mentioned PVS-Studio product is oriented on C and C++ applications in Windows system, Unix-developers (and developers working in other systems) will find the article useful too.

Introduction

With the phrase "near at hand is the day when all the developers will have to release 64-bit versions of their applications" I begin many articles since 2006, although now, when I am writing this article, 2009 is coming to end. Life has shown that I was wrong. That day is not so close. So many companies have not yet released 64-bit versions of their products. Partly it is due to the policy of Microsoft company that makes money equally well at selling 32-bit versions of Windows and 64-bit ones. And partly it is because far not all applications actually need the 64-bit versions.

But thanks to my experience of communicating with people responsible for decisions of developing applications' 64-bit versions, I understood that the main constraint is very simple. Many people simply do not know how to estimate time and value of the process of migrating an application to a 64-bit architecture. So, this ignorance makes them postpone the process of porting code as far as possible.

In this article I am going to tell you about one of the methods to estimate this process before migration. For it is possible to exactly tell how much time migration of a particular application takes only when this migration is over.

The article is based on the experience of OOO "Program Verification Systems" company's workers, both in porting various applications to 64-bit systems and using PVS-Studio code analyzer.

"Houston, Houston. Can we take off?"

This article is devoted to estimate of the migration process, but not the migration process itself. That's why I would refer those who want to examine the issue in detail to the article "Seven steps of migrating a program to a 64-bit system" [2]. Nevertheless, I will use some theses from that article here. Before we estimate the peculiarities of migration, we must have clear answers to the following questions:

  • Do we need to perform the very migration of code to 64-bit systems or is it enough just to make sure that a 32-bit application works on a 64-bit system?
  • Does the development tool used in the project support generation of 64-bit code?
  • Are there 64-bit versions of all the components and libraries used in the project?

If you answer "yes" to all these questions you face the main question put in the title of the article.

"Well, how to estimate the process of 64-bit migration?"

So, you have some (or some tens of) MBs of source code ready for migration. There is no configuration for building 64-bit code, and consequently no module compiled in 64-bit mode. But after reading the article "20 issues of porting C++ code on the 64-bit platform" [4] you understand that the process of searching all the hidden errors in the code will be difficult.

To understand how difficult the search of all the errors will be you can use static code analysis. There are various code analyzers (comparison of code analyzers, [3]) that you may use when searching problems in 64-bit code, but in this article I will stick to PVS-Studio code analyzer for it is this tool our company develops.

So, in PVS-Studio 3.30, you have a new ability of detecting problems relating to 64-bit code even in 32-bit projects. It is this ability that allows you to estimate complexity of migration BEFORE the step of creating the 64-bit configuration of the project. Earlier, PVS-Studio analyzer allowed testing projects only in the 64-bit configuration.

I would like to pay your attention to the mechanism of code testing in 32-bit mode. First of all, you should understand that of course this testing cannot be considered full, and correction of even all the detected problems cannot guarantee code's operability in 64-bit mode. For in the code of any serious application there will be fragments like this:

#ifdef WIN64
...
#endif

Of course, when testing the code in 32-bit mode, a fragment like this will be skipped. Or, more exactly: at the moment when there is no 64-bit configuration, there can be no fragment similar to this in the code. And when it does appear, the analyzer will "forget" to test it.

Another important point is that depending on the project's configuration data types are naturally different. That's why testing in 32-bit and 64-bit modes will nearly always give different results.

But how much will these results differ? Proceeding from the results of the experiments undertaken by our company, we give you the following data. The lists of diagnostic warnings generated by PVS-Studio code analyzer coincide 95-97% when testing projects both in 32-bit and 64-bit modes! This means that not more than 5% of diagnostic warnings differ. These results have been received in this way: we took the codes of real projects, tested them in 32-bit mode and saved the list of the problems detected. Then we tested the codes of the same projects in 64-bit mode and saved the list of the problems detected. After that we compared the two lists and estimated how many per cents of diagnostic warnings had coincided. For the whole procedure was performed in automated mode, the number of the projects tested was rather large (more than 20 projects, each several MBs in size). So, you can trust these results.

Of course you should not hurry to correct the detected potential errors in the 32-bit configuration - you should wait for the 64-bit configuration. But you can estimate how much time it will take to look through the code analyzer's warnings.

To get a time estimate I recommend that you do the following:

  • Perform analysis of the 32-bit configuration of the project with the help of PVS-Studio.
  • Ask a programmer who understands issues of 64-bit code to look through the warnings of the code analyzer for one day and decide whether this or that error is relevant to the project.
  • The general number of the code analyzer's warnings is divided into the number of the warnings examined by the programmer during one day.
  • The number you get is the number of man-hours necessary to migrate the code of the application to a 64-bit platform.

Of course there is a weak point in this algorithm of estimating the migration process - the programmer who will look through the warnings during a day. That's why I recommend that you take it seriously when choosing a person responsible for the estimate.

Here you are some recommendations on choosing such a programmer:

  • He must be a programmer with experience of not less than three years and, if possible, be familiar with the particular project to be tested.
  • He must be familiar with the issues of 64-bit code. The article "20 issues of porting C++ code on the 64-bit platform" [4] mentioned above is a good source of information on this topic.
  • It is desirable that he understand the principles of operating static code analyzers. This is not an obligatory requirement but understanding of the code static analysis technology makes estimate of the migration process more adequate.

Following these recommendations will allow you to get an adequate estimate of value and time of 64-bit migration of applications.

Conclusion

To better understand this article you should consider some points:

  • No tool (including PVS-Studio) can give any final estimate. It is always a person who gives an estimate. Sometimes using tools, sometimes without them.
  • PVS-Studio code analyzer is not intended for estimating the process of 64-bit migration; it does not give an estimate in hours (days, months). This is a tool detecting potential errors in 64-bit code. But proceeding from this information (when testing a 32-bit project) one can estimate man-hours needed for the project's port.
  • The quality of estimate depends on a person.

I wish you successful estimate of 64-bit migration of code and hope that PVS-Studio tool will help you in it.

References

Popular related articles
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…

Comments (0)

Next comments

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept