Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
In my previous posts, I covered a four-step strategy for preparing the application for the 64-bit porting process:
To wrap up this topic, I’d like to introduce a strategy for identifying defects on the 64-bit processor:
Recompile your application on the 64-bit processor. If you have trouble compiling it, work out all of the quirks related to compiler variations. You might also want to create static code analysis rules that will automatically identify the code associated with these quirks so that you can prevent these compilation problems from occurring in the future.
Some rules to consider are those that point out hard to port (to 64 bit) and error-prone code. For example, consider the following examples (more details are provided in this post):
A custom ruleset can be created from picking the critical rules needed just for this particular task. More rules can be added later, as needed.
After you locate and repair this error-prone code, start looking for code that works fine on your current platform/architecture, but that might not port well. Some rules that are applicable to most 64-bit porting projects include:
Once you recompile the code, perform static code analysis again to check if the new code complies with all appropriate coding standards. At this point, every change that should have been made but that was not made is an error. Fix these errors immediately! You don’t want to look for these errors as the application is running.
Link your application and try to build it.
At this point, you should try to run your code. If you have a problem getting code running on the 64-bit processor, use a unit testing framework to run the code function by function; that way, you can flush exactly what in the code is not portable. Test the function, and then fix the problem. Continue this process until the entire application is running.
Once the application is running, you’ll want to repeat run time error detection because the porting process is likely to cause some new problems that could not be detected before the port (for example, new memory corruption problems or different behaviors). If the run time error detection exposes problems, fix every bug related to porting.
***
Photo Credit: jurvetson
Want to learn more? Take a look at our Parasoft Insure++‘s product page to see how runtime error detection can expose memory corruption, memory leaks, access outside of array bounds, invalid pointers, and other defects.
Parasoft’s industry-leading automated software testing tools support the entire software development process, from when the developer writes the first line of code all the way through unit and functional testing, to performance and security testing, leveraging simulated test environments along the way.