Polyspace Static Analysis Notes

Read through the latest posts to learn more about Polyspace® products.

When you author software to simultaneously handle multiple tasks, you may use multithreaded programming—programs with constructs such as multiple entry points, interleaving of threads, and asynchronous interrupts. However, multithreaded programming is highly complex and introduces subtle defects such as data races and deadlocks. When such a defect occurs, it can take a long time to reproduce the issue and even longer to identify the root cause and fix it.

Data races are a common problem in multithreaded programming. Data races occur when multiple tasks or threads access a shared resource without sufficient protections, leading to undefined or unpredictable behavior.

Release 2021b provides new features and enhancements to Polyspace® products, including Polyspace as You Code—a new feature designed explicitly for developers.

The Polyspace® family of products now offers a feature designed explicitly for software developers: Polyspace as You Code. This feature brings the code checking capabilities of Polyspace Bug Finder into Integrated Development Environments (IDEs) and saves you from finding bugs late in the software development cycle.

The 2021a release of Polyspace® products adds improvements to many existing workflows. Run a faster analysis and view more precise results on C/C++ code that uses the AUTOSAR RTE API. Run Polyspace Code Prover™ analysis on a project that contains a mix of C and C++ source files. Reduce the software complexity of your code with the new customizable Guidelines checkers.

Release 2020b adds improvements to many existing Polyspace® product workflows. You can run a Polyspace analysis on C++17 code or use a Polyspace analysis to leverage source and compiler specifications generated in a JSON compilation database format from your build systems. 

Many companies that develop software for embedded systems are either investigating cloud platforms, planning pilot projects, or actively developing software in the cloud. These companies are often attracted to public cloud providers, such as Amazon Web Services (AWS®) and Microsoft Azure®, because of competitive pricing and other advantages that cloud platforms offer.

Release 2020a of the Polyspace® products complete many existing workflows and introduce some new capabilities. Polyspace Bug Finder™ now supports all CERT C rules, and Polyspace Access™ products can analyze all forms of C/C++ code that are imported into Simulink. New key features include checkers that detect potential performance problems in C++ code, flag functions from a user-curated list of deprecated functions, and check for issues in initialization code.

In the past 20 years, advancements in technologies such as mobile, smart devices, IoT, and the cloud have led to creation of millions of new applications. To develop applications faster with quality and predictability, companies are evolving their software development processes. In the early 2000s, “lightweight” agile software development started gaining popularity. Agile is an iterative software development process that places importance on collaboration, continuous planning, and continuous testing.

Release 2019b of the Polyspace® products contains more checkers, supports more compilers, shows fewer false positives, and reduces setup activities further compared to previous releases. Key new features include a shared variables mode in Polyspace Code Prover™, the ability to verify custom C code in Simulink®, and greater support for coding standards such as AUTOSAR C++14 and CERT® C++ with new post-C++11 checkers.

A question comes up often: Does Polyspace® support the compiler that I am using? Sometimes a variant of this question gets asked: Why does a static analysis tool like Polyspace need to know about a compiler? It’s not as if the tool compiles the code, creates a binary, and executes the binary to detect run-time errors. The run-time error detection does not involve executing the code at all.

Polyspace Bug Finder Access™ and Polyspace Code Prover Access™ make it easy to view analysis results and facilitate team collaboration. Everyone on the project team can view, comment, and triage results from a web interface. The following workflow shows how different members of a software development team can use Polyspace Access products to monitor software quality of their projects and view and triage code analysis and verification results.

As of R2019a, Polyspace Bug Finder™ has transitioned into three new products: Polyspace Bug Finder, Polyspace Bug Finder Server™, and Polyspace Bug Finder Access™. Polyspace Code Prover has also transitioned into three new products: Polyspace Code Prover, Polyspace Code Prover Server™, and Polyspace Code Prover Access™.

The 2018b release of Polyspace Bug Finder™ and Polyspace Code Prover™ offers many new features. Highlights include: easier set up, improved modularization, and increased support for security standards.

The Polyspace® development team considers the full customer experience, from the first interaction through the deployment of Polyspace products in your environment. The information we gain from you from these interactions drives our feature map and design.

By Jay Abraham, Puneet Lal, and Anirban Gangopadhyay

This article outlines two improvements in R2018a that make reviewing data races and other multitasking-based results much easier.

By Anirban Gangopadhyay

Starting in R2018a, Polyspace Code Prover directly supports the AUTOSAR (Automotive Open System Architecture) methodology for software development. Whatever your role in the AUTOSAR software development workflow, you can now use Polyspace Code Prover as an AUTOSAR-aware static analysis tool.

By Jay Abraham

Software engineers rely on integrated development environments (IDEs) such as Eclipse™ to consolidate development activities to a single unified interface. With IDEs, you can edit, compile, execute, debug, and test your code.

By Ram Cherukuri and Anirban Gangopadhyay

Buffer overflows have plagued the C/C++ development community for years. While the C language empowers developers to access memory directly via pointers, it also opens the door to overflow problems. Safe coding practices help developers avoid buffer overflows to some extent (at the cost of performance), but sometimes buffer overflows can be subtle and complex to find and resolve.

By Ram Cherukuri

MISRA published an amendment to its latest MISRA C:2012 coding guidelines to mitigate the growing risk of cyber security vulnerabilities. Published in early 2016, the amendment addresses embedded security through additional coding guidelines. These 14 new coding guidelines are aimed at bridging the gap within the security guidelines published in ISO/IEC 17961:2013. The table below identifies the classification of these 14 rules in line with the MISRA C 2012 specification. To learn more about the classification system used in the MISRA C:2012 standard, view Understanding Compliance to the MISRA C 2012 Coding Guidelines (33:28).

By Ram Cherukuri

Secure coding guidelines from CERT C, ISO/IEC TS 17961, MISRA C:2012 Amendment 1, and the security vulnerabilities schematized in CWE provide a way to analyze and measure the security of your embedded software. These standards are gaining more acceptance as they provide a common framework for understanding, addressing, and documenting security vulnerabilities in both existing and newly developed code.

By Ram Cherukuri

Organizations and teams adopt various models (i.e., V and Agile) for their software development processes. Within each model, there are differences variations, depending on the requirements of the application, the industry, and the maturity of the workflow. There are additional variations depending on the different steps in the software development workflow. For example, some organizations include a formal code review as part of their development process, given its benefits in improving the defect detection rates. Others rely solely or heavily on testing activities. Given these wide variations, there are at least a couple of best practices applicable to most modern embedded software development workflows.

By Ram Cherukuri

Polyspace Code Prover™ uses the color orange to highlight operations that can't be automatically proven to be error free under all circumstances. You can then review potential run-time issues that might lead to robustness or reliability concerns.

By Ram Cherukuri, Fred Noto, and Alexandre Langenieux

CERT C is a set of guidelines for software developers and is used for secure coding in C language. It was developed on the CERT community wiki following a community based development process, with the first edition released in 2008 and the second edition released in 2014.

By Ram Cherukuri

Code generation greatly simplifies the MISRA compliance process. The key objectives of coding standards (such as MISRA) are readability, maintainability, and portability, in addition to ensuring safety and reliability. Because the models are at the core of the development process and code can be generated from the model in a consistent manner for different platforms, it simplifies the portability and maintainability pieces.

By Ram Cherukuri

The previous post highlighted the benefits of leveraging Polyspace static analysis to help optimize and reduce the length of the testing phase of the verification cycle. This post will discuss the inefficiencies of robustness testing and introduce how to address those challenges.

By Ram Cherukuri

Testing is a major part of the verification process at most embedded software development organizations. Studies estimate that around 25 – 30% of development time is spent on testing, and in some cases, this can be as high as 50% [1].

By Ram Cherukuri, Gary Ryu

The most recent version of the MISRA standard coding rules is MISRA C:2012, which succeeds MISRA C:2004 that has been widely adopted in the software community across industries for embedded systems.

By Ram Cherukuri, Stefan David

MISRA standard is a widely adopted coding standard across industries. It has become a commonplace best practice among embedded software development and quality assurance groups. A lot of these groups have a strict adherence policy to at least a subset of applicable rules—if not all of the coding rules. Such a compliance policy would require a review process to address the violations of the coding rules, and this process can often be resource intensive.

By Ram Cherukuri

This reminds me of the joke asking, “How many engineers does it take to change a light bulb?“

Many of our customers, especially those in the automotive industry, have used more than one static analysis tool as part of their software development and verification process.

One reason for the use of multiple tools is that, traditionally, the adoption of static analysis was fragmented into different activities such as coding rule compliance, bug finding, and so on. The development organization may have adopted a lint tool to perform local bug finding and a rule-checking tool to verify compliance to standards such as MISRA, while the quality assurance department may have adopted tools for code metrics such as code coverage, comment density, and cyclomatic complexity.

By Anirban Gangopadhyay and Ram Cherukuri

In part one of this two part series, we discussed robustness code verification, a method in which you verify your unit of code in isolation from the rest of the code base. We outlined a few examples, and we discussed the pros and cons of using this approach.

In this post, we will discuss contextual code verification, in which you verify your unit of code in context of the code base where the unit will be integrated. This post will walk you through the concepts behind contextual code verification using the same examples as in the last post, and it will then outline the best practices for using both types of code verification (robustness and contextual).

By Anirban Gangopadhyay and Ram Cherukuri

This is part one of a two part series outlining code verification methods.

We begin with a question: At what stage of software development should I verify my code?

The answer is simple. You should verify it right after you have compiled it, when the code is fresh on your mind. Once you are shown potential errors, reviewing and fixing those errors can be almost trivial. Fixing errors never gets easier after that stage in the workflow.

By Ram Cherukuri, Jeff Chapple, Stefan David, and Jay Abraham

Faster time-to-market trends could possibly be driving the misconception that static analysis is only about finding bugs. Software developers must eliminate as many bugs as possible and will use a quick bug finding tool, though it is likely that some bugs will remain. This practice may be sufficient for non safety-critical applications such as smartphone apps, but it may be insufficient for safety-critical applications. Safety-critical applications, therefore, require more rigorous methods to verify safety and robustness, which is where the other benefits of static analysis come in. In this article we will bust the misconception that static analysis is only about finding bugs, and prove that it can help verify compliance to coding standards, produce metrics about code quality, and be used at any stage of software development.

By Jay Abraham, Ram Cherukuri, and Christian Bard

In February 2014, technology blogs and news outlets were abuzz about a newly discovered vulnerability in Apple’s iOS iPhone, iPod, iPad, and Mac OS X devices. There was a problem in the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) code that could be exploited by what is known as Man in the Middle attack (MitM). The vulnerability was dubbed Goto Fail, and Apple quickly patched the defect with iOS 7.0.6 for its mobile platform and OS X 10.9.2 for the desktop platform.