Competition time: Test your C programming skills

When Lonely Planet asked travelers for their ‘lost in translation’ photos of signs and menus from around the world, they had over 1,000, often hilarious, responses. Even when communicating in natural languages and dialects, the potential for confusion is immense. We see a similar but more serious issue of confusion around the C programming language.

C means nothing on its own

That’s because C has a multitude of dialects that are so similar it is impossible to tell which dialect is being used. There are some indicators, for example you may know that a certain extension is only present in one set of dialects. That will help you restrict the universe of possible dialects but it doesn’t come close to providing the accuracy and reliability needed in safety critical software analysis.

To add to the complication, C code is translated into machine code via toolchains that are constantly being amended and improved; and the new versions are not necessarily implementing the same dialects as the previous versions; so the number of C dialects increases over time. And every toolchain can implement, via options, many dialects. Many of the static analysis tools available on the market ignore these facts. They will interpret the code in a way that does not correspond to the dialect used in the toolchain.

That means the analysis results from many tools do not apply to the code that is actually embedded in the device. The task of configuring the tool manually is highly complex, time consuming and error prone. Therefore, to produce meaningful results in an efficient and safe way, the tool must automatically take differences in the toolchains into account.

Different dialects can significantly change the meaning

Many programmers seem to believe that the tools can somehow guess the C dialect the program is written in. They cannot. What is unique about BUGSENG’s ECLAIR verification tool is that it has been engineered, right from the start, to take dialect and toolchain differences into account in a completely automatic way.

The analysis from many other tools can be unreliable. What tends to happen is that the results state there is a problem when there is not. That means engineers waste valuable resources (potentially several days work) only to find that the problem doesn’t exist.

Even worse is when the tool fails to diagnose a real problem because of a mismatch between the dialect implemented by the toolchain and the dialect selected in the tool configuration. In this scenario, the engineer concludes there is no problem and the product goes into production. That often means huge costs further down the line to rectify the problem and, if the device is safety critical, to ensure with a high degree of confidence that the product conforms to the relevant industry safety standards.

This dialect phenomenon is peculiar to C and C++ and it is both their strength and weakness. The C family of languages has the versatility to adapt to completely different types of hardware; from microscopic devices to super computers. Even experienced programmers often overlook or misunderstand the extent and impact of the different dialects on code behavior.

Test your C programming skills

This brings us to our competition. This paper by Roberto Bagnara, BUGSENG’s CTO, contains an exercise that shows how a short piece of C code (less than 700 characters) can exhibit more than 700 different behaviors using just one toolchain, only changing the compilation options. But this can be taken further to many, many more different behaviors. So we have decided to hand the challenge over to you.

Along with the paper you can download the code and the scripts to automatically verify the results: the objective of the game is to extend them to obtain as many behaviors as possible, yet keeping the program small. Send us what you come up with: we will rank the solutions received, first by the number of behaviors (more is better), then on the size of the program (smaller is better), then on the time of arrival (sooner is better). The best three programs will win a fully-functional, time-limited ECLAIR license (instantiated over the package MISRA C:2012 + Bug Finder + HIS metrics):

1. The best program will win a 180-day license.
2. The second best program will win a 90-day license.
3. The third best program will win a 60-day license.

If you’d like to enter, you can find full details in Roberto’s paper. Then, please email your program to info@bugseng.com by Sunday 13 October 2019 at the latest. We’ll announce the winners on our blog.