Skip to content

Sonar
Syndicate content
Continuous Code Quality
Updated: 3 hours 16 min ago

SonarCFamily Now Supports ARM Compilers

Thu, 06/15/2017 - 16:08

For those not familiar with ARM (Advanced RISC Machine), let’s start by sharing some numbers: in 2011, the 32-bit ARM architecture was the most widely used architecture in mobile devices and the most popular 32-bit one in embedded systems (see). Moreover in 2013, 10 billion were produced (see) and “ARM-based chips are found in nearly 60 percent of the world’s mobile devices” (see).

Why ARM is so popular when dealing with embedded systems? Because the RISC architecture typically requires fewer transistors than those with a complex instruction set computing (CISC) architecture (such as the x86 processors found in most personal computers), which reduces cost, power consumption, and heat dissipation. These characteristics are desirable for light, portable, battery-powered devices‍—‌including smartphones, laptops and tablet computers, and other embedded systems.

Most developers targeting this ARM architecture, develop in C or C++ and use a compiler able to produce a binary for ARM machines. Both GCC and Clang support an ARM mode out-of-the-box. But if you want to generate a binary finely tuned to reduce the runtime footprint, you might want to go ahead with the ARM5, ARM6 or Linaro compilers.

SonarCFamily code analyzer version 4.8 adds support for all such compilers, this long-awaited feature finally becomes reality.

Analyzing a C/C++ project targeting the ARM architecture is not different than analyzing any other kind of C/C++ project but as a reminder here are the steps to follow:

# on Windows or on Linux, in a ARM DS-5 enabled environment:
make clean
build-wrapper-[win|linux]-x86-64 --out-dir <output directory> make
# set sonar.cfamily.build-wrapper-output= on sonar-project.properties
sonar-scanner

or, on Linux, from a console without ARM environment:

/usr/local/DS-5_v5.26.2/bin/suite_exec -t "ARM Compiler 5 (DS-5 built-in)" make clean
build-wrapper-linux-x86-64 --out-dir /usr/local/DS-5_v5.26.2/bin/suite_exec -t "ARM Compiler 5 (DS-5 built-in)" make
# set sonar.cfamily.build-wrapper-output=<output directory> on sonar-project.properties
sonar-scanner

Once you have analyzed the ARM compiled source code, you got the full power of the analysis available: hundred of rules available to track the nastiest issues, data-flow analysis included!

Of course, SonarCFamily 4.8 is compatible with SonarLint which means that ARM DS-5 developers using Eclipse or any Eclipse CDT developer will be able to use SonarLint and get their code analyzed on-the-fly. This enables to shorten the development feedback and catch issues “before they exist”!
SonarLint in action on Eclipse ARM DS-5

Categories: Open Source

The Tweets You Missed in May

Fri, 06/09/2017 - 15:22

Here are the tweets you likely missed last month!

SonarJava 4.9 Released: toward the goal to have more than 90% of the bugs being highly relevant, and 4 new rules.https://t.co/DVKoUmfNUE pic.twitter.com/w57Nxw9qgO

— SonarQube (@SonarQube) May 15, 2017

SonarC# 5.10 Released: 9 new rules and lot of improvements https://t.co/DhEnV6strV.
See example of unconditional jump in Roslyn pic.twitter.com/VwP4MpJcIp

— SonarQube (@SonarQube) May 12, 2017

SonarJS 3.0 Released: Being Lean and Mean in JavaScript. Blog Entry: https://t.co/bItwkfgsSf and Product News: https://t.co/TjXHmKXvaR pic.twitter.com/X9lAqi8q9k

— SonarQube (@SonarQube) May 1, 2017

SonarPython 1.8 Released: to track unused and self-assigned variables.
see https://t.co/8x0LzBYOqZ#python pic.twitter.com/QQLQ09aumT

— SonarQube (@SonarQube) May 22, 2017

SonarLint for IntelliJ 2.10 released: many rules fine-tuned for high accuracy in bug detection and 4 new rules https://t.co/YRbsOhWSnk pic.twitter.com/n0NHf5B8az

— SonarLint (@SonarLint) May 30, 2017

SonarLint for Eclipse 3.1 refines the analysis of JavaScript to focus on bugs. https://t.co/QMrab1IAlw pic.twitter.com/D2wgkoNgL1

— SonarLint (@SonarLint) May 10, 2017

SonarLint for Visual Studio 2.13 brings 9 additional rules https://t.co/b8G4lBX6Qv pic.twitter.com/X28DsueVke

— SonarLint (@SonarLint) May 8, 2017

Categories: Open Source

Kill the Noise! to Change Gear in our Code Analyzers

Thu, 06/01/2017 - 15:48

Over the past few weeks, you may have noticed that most of our product news about code analyzers contained a mention of a “Kill The Noise!” project. We initiated this project at the beginning of the year to sharpen the detection of issues of type “Bug” on certain code analyzers: SonarJS, SonarC#, SonarJava and SonarCFamily. In simpler words, it means that our objective with this project is to make sure that when a SonarQube users clicks on “Bugs” on a project homepage he will be able to fix real and nasty bugs instead of trying to figure out whether the issues he is looking at are real bugs or not.

That may sound like an obvious and mandatory behavior for code analyzers to be extremely sharp when reporting bugs, but do you actually know any analyzer on the market that has at least 90% accuracy?

Over the past two years, we have developed the technology to do path-sensitive DFA (data flow analysis) on C#, Java, JavaScript, C and C++. This technology allows us to go through all execution paths while symbolically simulating the execution of each statement. With help of those DFA engines, we’re able to spot tricky bugs like this one in the Linux kernel:
linux-bug

And then we realized two things :

  • A lot of our older rules of type “Bug” were not really finding obvious bugs, but were more reinforcing good coding practices that help make the code more robust, and therefore reliable. Here are few examples: Non empty switch cases should end with unconditional break statement or Two branches in a conditional structure should not have the same implementation. Those rules spot some real quality issues but most of the time such implementations were done on purpose, and don’t actually lead to unexpected behavior in production.
  • Some rules combined the detection of bugs and quality issues. That was for instance the case for the rule to detect unconditionally true/false conditions. Sounds strange? Here is the reasoning: when a branch is fully unreachable due to an unconditionally false condition there is no doubt about the fact that it is a bug. But when a (sub)condition is unconditionally true, it might be on purpose just to make the code more self-explanatory: Boom! A rule that finds both bugs and quality issues

So we made an effort of reclassification and split of rules. Obviously we made all this while keeping the hunt for the infamous false-positives.

At the end we are all working at SonarSource towards this ultimate goal to have code analyzers being at least 90% accurate when raising issues of type “Bug” and we are not far from making this dream become a reality. Obviously any feedback on the latest versions of SonarJS, SonarC#, SonarJava and SonarCFamily is highly welcome to help us Kill the Noise!

Categories: Open Source

Accelerate Products Development at SonarSource

Wed, 05/10/2017 - 16:53

We founded SonarSource 8 years ago with a dream to one day provide every developer the ability to measure the code quality of his projects. And we had a motto for this: “Democratize access to code quality tooling”. To make this dream come true we invested all our time and energy into developing the SonarQube platform, hiring a great team and building an open source business model to sustain the company growth and keep our freedom. We have also invested a lot in the relationship with our community; giving a lot and also getting back a lot.

Thanks to this approach, here are some examples of what we were able to deliver in the last few years:

  • on-the-fly Feedback in the IDE with SonarLint
  • analysis of 18 languages
  • deep analysis to cover the reliability and security domains
  • high availability and multi-tenancy of the platform to soon launch sonarqube.com

After 8 years of effort, we believe we have built great products along with an awesome 60-person company, a solid business and a great brand. We are very proud of these, but we do not think our dream has come true yet. Why? Because Continuous Code Quality still isn’t a commodity the way SCM, Continuous Integration, and artifacts management are: every developer should benefit from the power of a path-sensitive, context-sensitive data flow analysis engine to detect the nastiest bugs and subtlest security vulnerabilities. sonarqube.com should be a no-brainer for anyone who uses Github.com, VSTS, Travis CI… In other words, everyone writing code should want to benefit from the best analyzers to make sure each line produced is secure, reliable and maintainable.

To take up this challenge, we have made a choice to partner with Insight Venture Partners, one of the very best VCs in our domain. By leveraging their experience, we strongly believe we will be making our dream come true… way sooner than another 8 years!

Simon, Freddy & Olivier
The SonarSource Founders

Categories: Open Source

The Tweets You Missed in April

Fri, 05/05/2017 - 14:58

Here are the tweets you likely missed last month!

SonarQube 6.3 released: read the news and see in it screenshots! https://t.co/5SejxD5Gflhttps://t.co/itdHN7tu6p pic.twitter.com/dMjp6Zg2aS

— SonarQube (@SonarQube) April 12, 2017

SonarCFamily 4.7 Released: 4 new rules and a dataflow engine supporting precise values for integer literals https://t.co/SUL1QVr0nu pic.twitter.com/eVY69DRcsE

— SonarQube (@SonarQube) April 12, 2017

SonarCOBOL 3.4 Released: 8 new rules https://t.co/s7M1JLUq04#cobolForEver pic.twitter.com/QyYx0p0ChT

— SonarQube (@SonarQube) April 13, 2017

SonarLint for IntelliJ 2.9 shows paths across methods calls that lead to an exception https://t.co/0S8Ch2Wylt pic.twitter.com/Yd2dmR7OdB

— SonarLint (@SonarLint) April 6, 2017

SonarLint for Eclipse 3.0 detects tricky issues on Java and JavaScript thanks to an extended dataflow analysis https://t.co/LQ8WnW6A3E pic.twitter.com/niRpICPOef

— SonarLint (@SonarLint) April 18, 2017

Categories: Open Source