{"id":407589,"date":"2024-06-29T19:38:43","date_gmt":"2024-06-29T19:38:43","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=407589"},"modified":"-0001-11-30T00:00:00","modified_gmt":"2024-06-29T19:38:43","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=407589","title":{"rendered":"C# Programmer, It’s Time to Test Yourself and Find Error<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

The PVS-Studio analyzer is regularly updated with new diagnostic rules. Curiously enough, diagnostics often detect suspicious code fragments before the end of the work. For example, such a situation may happen while testing on open-source projects. So, let’s take a look at one of these interesting finding.<\/p>\n

<\/figcaption><\/figure>\n

As mentioned earlier, one of the stages of diagnostic rule testing is to check its operation on a real codebase. To that end, we have a set of selected open-source projects that we use for the analysis. The obvious advantage of this approach is the ability to see the diagnostic rule behavior in real conditions. There’s also a less obvious advantage. Sometimes you may find such an interesting case, so it would be a sin not to write an article about it. \ud83d\ude42<\/p>\n

Now, let’s take a look at the code from the Bouncy Castle C# project and find the error in it:<\/p>\n

public static string ToString(object[] a) {   StringBuilder sb = new StringBuilder('[');   if (a.Length > 0)   {     sb.Append(a[0]);     for (int index = 1; index < a.Length; ++index)     {       sb.Append(\", \").Append(a[index]);     }   }   sb.Append(']');   return sb.ToString(); } <\/code><\/pre>\n
For those who like to cheat and peek, I added a picture to keep you guessing.<\/p>\n
<\/figcaption><\/figure>\n
I’m sure some of you couldn’t see the error without using the IDE or the StringBuilder<\/em> class documentation. The error happened when calling the constructor:<\/p>\n
StringBuilder sb = new StringBuilder('['); <\/code><\/pre>\n
Actually, this is exactly what the PVS-Studio static analyzer warns us about: V3165<\/a> Character literal ‘[‘ is passed as an argument of the ‘Int32’ type whereas similar overload with the string parameter exists. Perhaps, a string literal should be used instead. Arrays.cs 193.<\/p>\n
The programmer wanted to create an instance of the StringBuilder<\/em> type, where the string begins with the ‘[‘ character. However, due to a typo, we’ll have an object without any characters with a capacity of 91 elements.<\/p>\n
This happened because the programmer used single quotes instead of double-quotes. That’s why the wrong constructor overload was called: <\/p>\n
.... public StringBuilder(int capacity); public StringBuilder(string? value); .... <\/code><\/pre>\n
When the constructor is called, the ‘[‘ character literal will be implicitly cast to the corresponding value of the int<\/em> type (91 in Unicode). Because of this, the constructor with the int<\/em> type parameter setting the initial capacity will be called. Although, the programmer wanted to call the constructor which sets the string’s beginning.<\/p>\n
To fix the error, the developer has to replace the character literal with a string literal (i.e., use «[» instead of ‘[‘). It will cause the correct constructor overload.<\/p>\n
We decided to go the extra mile and expanded the cases reviewed by diagnostic. As a result, in addition to character literals, some other expressions of the char<\/em> type are considered now. We also check methods in the same way. <\/p>\n
The diagnostic described above was added in the PVS-Studio 7.11 release. You can download the analyzer latest version<\/a> yourself. You’ll see what the V3165 diagnostic can do, as well as other diagnostics for C, C++, C#, and Java.<\/p>\n
By the way, the users themselves often suggest some ideas of diagnostics to us. This time it has happened thanks to the user of Krypt<\/a> from Habr. If you also have some ideas for diagnostic rules — don’t hesitate to reach out to us<\/a>!<\/p>\n
P.S.<\/strong> This error has already been fixed in the current project code base. Though, this doesn’t change the fact that it has existed in the code for some time, and that static analysis allows you to identify such problems and fix them at the earliest stages.<\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n

 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438  https:\/\/habr.com\/ru\/articles\/540348\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
<\/div>\n
\n
\n
\n
\n
The PVS-Studio analyzer is regularly updated with new diagnostic rules. Curiously enough, diagnostics often detect suspicious code fragments before the end of the work. For example, such a situation may happen while testing on open-source projects. So, let’s take a look at one of these interesting finding.<\/p>\n
<\/figcaption><\/figure>\n
As mentioned earlier, one of the stages of diagnostic rule testing is to check its operation on a real codebase. To that end, we have a set of selected open-source projects that we use for the analysis. The obvious advantage of this approach is the ability to see the diagnostic rule behavior in real conditions. There’s also a less obvious advantage. Sometimes you may find such an interesting case, so it would be a sin not to write an article about it. \ud83d\ude42<\/p>\n
Now, let’s take a look at the code from the Bouncy Castle C# project and find the error in it:<\/p>\n
public static string ToString(object[] a) {   StringBuilder sb = new StringBuilder('[');   if (a.Length > 0)   {     sb.Append(a[0]);     for (int index = 1; index < a.Length; ++index)     {       sb.Append(\", \").Append(a[index]);     }   }   sb.Append(']');   return sb.ToString(); } <\/code><\/pre>\n
For those who like to cheat and peek, I added a picture to keep you guessing.<\/p>\n
<\/figcaption><\/figure>\n
I’m sure some of you couldn’t see the error without using the IDE or the StringBuilder<\/em> class documentation. The error happened when calling the constructor:<\/p>\n
StringBuilder sb = new StringBuilder('['); <\/code><\/pre>\n
Actually, this is exactly what the PVS-Studio static analyzer warns us about: V3165<\/a> Character literal ‘[‘ is passed as an argument of the ‘Int32’ type whereas similar overload with the string parameter exists. Perhaps, a string literal should be used instead. Arrays.cs 193.<\/p>\n
The programmer wanted to create an instance of the StringBuilder<\/em> type, where the string begins with the ‘[‘ character. However, due to a typo, we’ll have an object without any characters with a capacity of 91 elements.<\/p>\n
This happened because the programmer used single quotes instead of double-quotes. That’s why the wrong constructor overload was called: <\/p>\n
.... public StringBuilder(int capacity); public StringBuilder(string? value); .... <\/code><\/pre>\n
When the constructor is called, the ‘[‘ character literal will be implicitly cast to the corresponding value of the int<\/em> type (91 in Unicode). Because of this, the constructor with the int<\/em> type parameter setting the initial capacity will be called. Although, the programmer wanted to call the constructor which sets the string’s beginning.<\/p>\n
To fix the error, the developer has to replace the character literal with a string literal (i.e., use «[» instead of ‘[‘). It will cause the correct constructor overload.<\/p>\n
We decided to go the extra mile and expanded the cases reviewed by diagnostic. As a result, in addition to character literals, some other expressions of the char<\/em> type are considered now. We also check methods in the same way. <\/p>\n
The diagnostic described above was added in the PVS-Studio 7.11 release. You can download the analyzer latest version<\/a> yourself. You’ll see what the V3165 diagnostic can do, as well as other diagnostics for C, C++, C#, and Java.<\/p>\n
By the way, the users themselves often suggest some ideas of diagnostics to us. This time it has happened thanks to the user of Krypt<\/a> from Habr. If you also have some ideas for diagnostic rules — don’t hesitate to reach out to us<\/a>!<\/p>\n
P.S.<\/strong> This error has already been fixed in the current project code base. Though, this doesn’t change the fact that it has existed in the code for some time, and that static analysis allows you to identify such problems and fix them at the earliest stages.<\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n

 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438  https:\/\/habr.com\/ru\/articles\/540348\/<\/a>
<\/br><\/br><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-407589","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/407589","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=407589"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/407589\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=407589"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=407589"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=407589"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}