Continuing to explore Tizen: C # components turned out to be of high quality.

Today I return to the project Tizen. In my recent post “Error Testing in Tizen C # Component Code” in our blog, I conducted a superficial analysis and concluded that it makes sense to check all the C # code of components of this project for errors using the PVS-Studio analyzer and write about it an article. Without delay, I did this work and want to share its results with you. I’ll say right away that in C # code, the PVS-Studio analyzer showed itself weakly. But first things first: let's see what the analyzer was able to find, and then let's look at the statistics and summarize.

Introduction

My colleague Andrei Karpov recently published two epic articles on the analysis of the Tizen project code written in C and C ++ languages:

1. 27000 errors in the Tizen operating system
2. Let's talk about micro-optimizations on the example of Tizen code

When I noticed that the Tizen project included code in C #, I wanted to do a similar article about testing components written in that language. Unfortunately, this time the analyzer was unable to demonstrate striking successes, but let's not hurry and examine the issue in detail.

What I checked

The Tizen source code is available for download at the link . The repository contains about 1,000 projects, each of which consists of an archive with source code, as well as auxiliary files. By the names of the archives or the description is not always possible to understand what is inside. Therefore, it was necessary to download, unpack and examine archives for the entire repository.
')
In the previous article, I gave the total number of C # source code files (4,929, excluding * .Designer.cs) and the lines of code in them (about 691,000) contained in the Tizen project. Now we need a more detailed analysis. First, let's try to find files with the .sln or .csproj extension. The presence of such files will allow analysis in Visual Studio IDE, which will greatly simplify the work.

So, during the search, 227 solutions (* .sln) and 166 C # projects (* .csproj) were found. From the decision files, I chose those that contained C # projects. There were only 3 such solutions:

• Tizen.Xamarin.Forms.Extension.sln
• Xamarin.Forms.Tizen.sln
• Xamarin.Forms.sln

The first two solutions are a Tizen add-on over a third-party Xamarin.Forms component, and the third one contains the component itself. Just over a year ago we wrote an article about checking Xamarin.Forms. In my work, I will consider these results and try to find new errors.

Next, by excluding the project files (* .csproj) included in these solutions, I received 107 C # projects that were not associated with any decisions. Almost all of them are in top-level folders with names like "csapi- *". Eliminating from this number 11 test projects, as well as 9 projects that had an unsupported Visual Studio format, I received 87 projects in the remainder. Each of them I checked separately.

For the purity of the research, I decided to separate the results obtained for the internal C # components of Tizen (the same 87 projects) from the results of testing components based on Xamarin.Forms. At first I didn’t want to take into account Xamarin.Forms, but, on reflection, I came to the conclusion that since Tizen uses this component for its own purposes, then Xamarin.Forms errors can have an effect on Tizen.

Also, I will not describe the errors that have already been cited in the previous article .

Test results

Tizen internal C # components

During the verification of this part of the Tizen project, the PVS-Studio analyzer issued 356 warnings, 18 of them - High confidence level, 157 - Medium confidence level and 181 - Low confidence level. About 325,000 lines of code were analyzed.

I did not consider the warnings of the Low confidence level, since the percentage of false positives is usually high there. However, unfortunately, many false positives this time are not only at the Low level. Among 175 warnings of the High and Medium levels I managed to detect only 12 errors. Let's take a look at the most interesting.

PVS-Studio warning : V3008 The '_scanData' variable is assigned values ​​twice successively. Perhaps this is a mistake. Check lines: 138, 137. Tizen.Network.Bluetooth BluetoothLeAdapter.cs 138
CWE-563. Assignment to Variable without Use ('Unused Variable')

internal BluetoothLeDevice(BluetoothLeScanData scanData) { _scanData = new BluetoothLeScanData (); _scanData = scanData; .... } 

The _scanData field is assigned a value twice. Looks very suspicious. Just in case, take a look at the BluetoothLeScanData class declaration and its constructor. Perhaps the constructor call contains some additional actions. The class is small, so I’ll quote it entirely, formatting the original code a bit:

 internal class BluetoothLeScanData { internal string RemoteAddress { get; set; } internal BluetoothLeDeviceAddressType AddressType { get; set; } internal int Rssi { get; set; } internal int AdvDataLength { get; set; } internal byte[] AdvData { get; set; } internal int ScanDataLength { get; set; } internal byte[] ScanData { get; set; } } 

As you can see, the class does not contain an overridden default constructor, therefore, apparently, double assignment of the value to the _scanData field is an error.

PVS-Studio Warning: V3009 This is the same way that this method returns. Tizen.Applications.WidgetApplication WidgetType.cs 47
CWE-393. Return of Wrong Status Code

 private int OnCreate(....) { WidgetBase b = Activator.CreateInstance(ClassType) as WidgetBase; .... if (b == null) return 0; .... return 0; } 

The method always returns 0, regardless of the result of its work. Probably made a mistake that can be fixed, for example, like this:

 private int OnCreate(....) { WidgetBase b = Activator.CreateInstance(ClassType) as WidgetBase; .... if (b == null) return 0; .... return 1; } 

PVS-Studio warnings:

• V3022 Expression '! LeftBoundIsForward' is always false. clipper_library clipper.cs 838
• V3022 Expression '! LeftBoundIsForward' is always true. clipper_library clipper.cs 863

CWE-570 / CWE-571 Expression is Always False / True

 private TEdge ProcessBound(TEdge E, bool LeftBoundIsForward) { .... if (LeftBoundIsForward) { .... if (!LeftBoundIsForward) Result = Horz.Prev; .... } else { .... if (!LeftBoundIsForward) Result = Horz.Next; .... } .... } 

This code snippet immediately contains 2 of the same type of erroneous checks. In this case, in the first case, the Result variable will never get the value of Horz.Prev , and in the second case, the same Result variable will always get the value of Horz.Next . The author should carefully study this code and correct the error on its own.

PVS-Studio warning : V3022 Expression 'e.OutIdx> = 0' is always true. clipper_library clipper.cs 3144
CWE-571 Expression is Always True

 private void DoMaxima(TEdge e) { .... if(....) { .... } else if( e.OutIdx >= 0 && eMaxPair.OutIdx >= 0 ) { if (e.OutIdx >= 0) AddLocalMaxPoly(e, eMaxPair, e.Top); .... } .... } 

Another piece of code with erroneous verification. It is possible if the operator "||" was used in the condition e.OutIdx> = 0 && eMaxPair.OutIdx> = 0 , then checking e.OutIdx> = 0 in the nested if block would make sense. Now it looks suspicious.

PVS-Studio warning : V3110 Possible infinite recursion inside 'InsertBefore' method. ElmSharp Toolbar.cs 288
CWE-674 Uncontrolled Recursion

 public ToolbarItem InsertBefore(ToolbarItem before, string label) { return InsertBefore(before, label); } 

Calling the InsertBefore method generates infinite recursion. Probably an error was made due to calling the wrong method overload. There is another method in the code named InsertBefore :

 public ToolbarItem InsertBefore(ToolbarItem before, string label, string icon) { .... } 

Perhaps these are all interesting errors of this section. There are some more suspicious parts of the code, but I will not dwell on them. The code from Samsung Electronics, written in C #, demonstrates good quality. Why am I so sure that the verified code is Samsung authorship? Yes, because each of the scanned files contained in its heading a comment like "Copyright © 2016 Samsung Electronics Co., Ltd All Rights Reserved".

Tizen components based on Xamarin.Forms

The add-on used in Tizen over Xamarin.Forms contains about 242,000 lines of code. During its verification, the PVS-Studio analyzer issued 163 warnings, of which 10 were High confidence levels, 46 were Medium confidence levels and 107 were Low confidence levels (not considered).

As promised, I will try to find errors that were not described in the previous article about checking Xamarin.Forms. By the way, I did not find some of the errors listed there during the new check. Apparently, they were corrected after the authors got acquainted with the article.

Despite the small number of warnings issued, I managed to find several new errors among them.

PVS-Studio warning : V3095 The 'context' object was verified against null. Check lines: 16, 18. Xamarin.Forms.Xaml XamlServiceProvider.cs 16
CWE-476 NULL Pointer Dereference

 internal XamlServiceProvider(INode node, HydratationContext context) { .... if (node != null && node.Parent != null && context.Values.TryGetValue(node.Parent, // <= out targetObject)) IProvideValueTarget = new XamlValueTargetProvider(....); if (context != null) // <= IRootObjectProvider = new XamlRootObjectProvider(context.RootElement); .... } 

The context variable is first used, and only then it is checked for null equality.

PVS-Studio warning : V3095 The 'type' object was verified against null. Check lines: 147, 149. Xamarin.Forms.Xaml ExpandMarkupsVisitor.cs 147
CWE-476 NULL Pointer Dereference

 public INode Parse(....) { .... var xmltype = new XmlType(namespaceuri, type.Name, null); // <= if (type == null) throw new NotSupportedException(); .... } 

Another example of a possible throw exception is a NullReferenceException . The type variable is used to create an instance of the XmlType class, and then it is checked for null equality.

Other similar errors:

• V3095 The 'e.NewElement' object was used against it. Check lines: 32, 46. Xamarin.Forms.Platform.Tizen MasterDetailPageRenderer.cs 32
• V3095 The 'e.NewItems' object was used against it. Check lines: 557, 567. Xamarin.Forms.Core Element.cs 557
• V3095 The 'e.OldItems' object was verified against null. Check lines: 561, 574. Xamarin.Forms.Core Element.cs 561
• V3095 The 'part' object was used against it. Check lines: 135, 156. Xamarin.Forms.Core BindingExpression.cs 135

PVS-Studio Warning: V3125 The 'e.NewItems' object was used against null. Check lines: 999, 986. Xamarin.Forms.Core TemplatedItemsList.cs 999
CWE-476 NULL Pointer Dereference

 void OnProxyCollectionChanged(....) { .... if (e.NewStartingIndex >= 0 && e.NewItems != null) // <= maxindex = Math.Max(maxindex, e.NewStartingIndex + e.NewItems.Count); .... for (int i = e.NewStartingIndex; i < _templatedObjects.Count; i++) SetIndex(_templatedObjects[i], i + e.NewItems.Count); // <= .... } 

And here - the opposite situation. The e.NewItems variable is checked for null equality before first use. However, when reused, this is forgotten.

Statistics

As my colleague Andrei Karpov wrote in one of the previous articles, the PVS-Studio analyzer reveals about 0.4 errors per 1000 lines of C / C ++ Tizen project code. Let's calculate what we get for C # code.

In total, about 567,000 lines of C # code were tested.

In my opinion, only 15 code fragments have been found, about which it can be said that they contain errors.

It turns out that the analyzer detects 0.02 errors per 1000 lines of code. Or, in other words, it finds 1 error per 50,000 lines of code. Not much.

We have to admit that in this case the analyzer was unable to demonstrate its usefulness. Why it happened - it's hard to say. When checking other open projects, the analyzer often showed good results. For example , when checking open components of Unity3D, the density of detected errors was 0.5 errors per 1000 lines of code. Those. the rate was 25 times better.

It is possible that the components that have been tested today are of very high quality, perhaps the analyzer cannot find the types of errors inherent in this project. Maybe the reason for that is Tizen's complex infrastructure. Often, projects that did not contain all the necessary environment were checked, many links were missing, which did not allow some diagnostics to work out. Some projects I could not check.

findings

So, the result of the check was not the same as I expected for this amount of code. To be honest, I assumed to find at least several hundred errors, but there were about fifteen.

However, it is important that the PVS-Studio analyzer coped with the task of analyzing the C # code of the Tizen project. So, it may be useful, if not now, then later, when new components written using C # language will appear in Tizen. The potential benefit is confirmed by the huge number of errors that the analyzer has already found in other open source projects (see the list of articles ).

Moreover, as we are not tired of repeating, the script of single checks using the analyzer is not optimal - errors are already embedded in the version control system, which, you see, is bad. It is much more efficient to use a static analyzer on a regular basis, which will make it possible to correct errors at the stage of writing code, until it reaches the version control system, because in this case the cost and complexity of correcting them is much lower.

Download and try PVS-Studio

Additional links

1. An experiment to find errors in the C # code of Tizen components
2. Microsoft opened the source Xamarin.Forms. We could not miss the chance to check them with PVS-Studio
3. PVS-Studio team is ready to work on the Tizen project (open letter)
4. We provide the PVS-Studio analyzer to security experts
5. How can PVS-Studio help in finding vulnerabilities?
6. 27000 errors in the Tizen operating system
7. Let's talk about micro-optimizations on the example of Tizen code

If you want to share this article with an English-speaking audience, then please use the link to the translation: Sergey Khrenov. We Continue Exploring Tizen: C # Components Proved to be High Quality