Nullable Reference Will Not Protect you, and Here Is the Proof
Have you ever wanted to get rid of the problem with dereferencing null references? If so, using Nullable Reference types is not your choice.
Join the DZone community and get the full member experience.Join For Free
Have you ever wanted to get rid of the problem with dereferencing null references? If so, using Nullable Reference types is not your choice. Do you want to know why? This will be our topic today.
We warned you, and it happened. About a year ago, my colleagues wrote an article in which they warned that the introduction of Nullable Reference types will not protect against dereferencing null references. Now we have indisputable proof of what we were saying found in the depths of Roslyn.
Nullable Reference Types
The idea itself of adding Nullable Reference (further as NR) types seems noteworthy to me since the problem related to dereferencing null references is still relevant to this day. Nevertheless, the implementation of protection against dereferencing turned out to be extremely unreliable. According to the idea of creators, only those variables whose type is marked with the "?" symbol can accept the null value. For example, a variable of the string? type indicates that it might contain null, and a variable of the string type might imply the opposite
However, nobody's stopping us from passing null to non-nullable reference variables (further as - NNR) of types, because they are not implemented at the IL code level. The compiler's built-in static analyzer is responsible for this limitation. Therefore, this new feature is more of a recommendation. Here is a simple example showing how it works:
As we can see, the nonNullable type is specified as NNR, but we can safely pass null there. Of course, we will get a warning about converting "Converting null literal or possible null value to non-nullable type". However, we can get around it a bit more aggressively:
One exclamation mark and there are no warnings. If you're a nitpicker, the following option is also available:
Here's another example. Let's create two simple console projects. In the first we write:
In the second one we write:
Hover the cursor over nullOrNotNull and see this message:
It's a hint that the string here can't be null. But we already know that it will be null right here. Run the project and get the exception:
Sure, these are just synthetic examples that demonstrate that this feature doesn't guarantee you protection from dereferencing a null reference. If you consider synthetic examples to be boring and you're wondering where real examples are, don't worry — they will be further in the article.
NR types also have another problem - it's not clear whether they are enabled or not. For example, the solution has two projects. One is marked up using this syntax, and the other is not. When you go to the project with NR types, you can decide that if one is marked up, then all are marked up. However, this will not be the case. It turns out that you need to check every time whether a nullable context is enabled in a project or file. Otherwise, you might mistakenly assume that the normal reference type is NNR.
How We Found Proofs
When developing new diagnostics in the PVS-Studio analyzer, we always test them on our database of real projects. This helps for several reasons. For example, we can:
- Watch "live" the quality of received warnings;
- Get rid of some false positives;
- Find interesting fragments in the code which you can tell someone about;
One of the new diagnostics - V3156 found places where exceptions can occur due to potential null. The diagnostic message is as follows: "The argument of the method is not expected to be null". Its main point is that a null value can be passed as an argument to a method that does not expect null. This can lead, for example, to an exception or incorrect execution of the called method. You can read more about this diagnostic rule here.
Proofs Are Here
So here we are in the main part of this article. get ready to see real code fragments from the Roslyn project which the diagnostic issued warnings for. Their underlying idea is that either the NNR type is passed null, or there is no checking of the NR type value. All of this can result in an exception.Example 1
V3156 The first argument of the 'ContainsKey' method is not expected to be null. Potential null value: key. SwitchBinder.cs 121
The message states that the key is potential null. Let's see where this variable can get this value. Let's check the KeyForConstant method first:
Since s_nullKey is not null, see what constantValue.Value returns:
There are two null literals here, but in this case, we won't go into any case with them. This is due to IsBad and IsNull checks. However, I would like to draw your attention to the return type of this property. It is an NR type, but the KeyForConstant method already returns the NNR type. It turns out that normally the KeyForConstant method can return null.
Another source that can return null is the AsNode method:
Again, please note the return type of the method - it is NR. It turns out that when we say that a method can return null, it doesn't affect anything. What's interesting here is the fact that the compiler here does not complain about the conversion from NR to NNR:Example 2
V3156 The first argument of the 'Add' method is not expected to be null. Potential null value: oldNode. SyntaxAnnotationTests.cs 439
Another example with the AsNode function, which was described above. Only this time oldNode will have the NR type. While the key described above had the NNR type.
By the way, I can't help but share an interesting finding with you. As I described above, when developing diagnostics, we check them on different projects. When checking the warnings of this rule, I noticed a curious thing. About 70% of all warnings were issued for methods of the Dictionary class. In which most of them fell on the TryGetValue method. This may be because we subconsciously do not expect exceptions from a method that contains the word try. So, check your code for this pattern, you might find something similar.Example 3
V3156 The first argument of the 'Add' method is passed as an argument to the 'TryGetValue' method and is not expected to be null. Potential null value: typeName. SymbolTreeInfo_Serialization.cs 255
The analyzer says that the problem is in typeName. Let's first make sure that this argument is indeed a potential null. Now look at ReadString:
Ok, check out ReadStringValue:
Great, now let's recall where our variable was passed to:
I think it's high time we took a peek inside the Add method:
Indeed, if we pass null as the first argument to the Add method, we will get the ArgumentNullException.
By the way, here's what's interesting - what if we hover the cursor over typeName in Visual Studio, will we see that its type is a string?:
The return type of the method is simply string:
In addition, if we create an NNR variable and assign it typeName, no error will be output.
Let's Crash Roslyn
Doing this not out of spite, but for fun, I suggest trying to reproduce one of the examples shown.Test 1
Let's take the example described under number 3:
To reproduce it, we will need to call the TryReadSymbolTreeInfo method, but it is private. The good thing is that the class with it has the:
ReadSymbolTreeInfo_ForTestingPurposesOnly method, which is already internal:
It is very nice that we are simply offered to test the TryReadSymbolTreeInfo method. So, let's create our own class right here and write the following code:
Now we build Roslyn, create a simple console application, include all the necessary DLL files, and write this code:
Run, reach the desired point, and see:
Next, go to the Add method and get the expected exception:
Let me remind you that the ReadString method returns an NNR type that cannot contain null as intended. This example once again confirms the relevance of the PVS-Studio diagnostic rules for searching for dereferencing null links.Test 2
Well, since we have already started reproducing examples, why not reproduce another one. This example will not relate to NR types. However, the same V3156 diagnostic found it, and I wanted to tell you about it. Here's the code
V3156 The sixth argument of the 'GenerateUniqueName' method is passed as an argument to the 'Concat' method and is not expected to be null. Potential null value: null. AbstractSemanticFactsService.cs 24
I'll be honest: when making this diagnostic, I didn't really expect triggering warnings for simple null. After all, it is quite strange to pass null to a method that throws an exception because of it. Although I have seen places where this was justified (for example, with the Expression class), that's not the point now.
So, I was very intrigued when I saw this warning. Let's see what is happening in the GenerateUniqueName method.
As we can see, there is only one exit point in the method, no exceptions are thrown and there is no goto. In other words, nothing prevents us from passing usedNames to the Concat method and getting the ArgumentNullException.
But talk is cheap, so let's just do it. First, we have to find out where we can call this method. The method itself is in the AbstractSemanticFactsService class. The class is abstract, so for convenience, let's take the CSharpSemanticFactsService class, which is inherited from it. In the file of this class, we'll create our own one, which will call the GenerateUniqueName method. It looks like this:
Now we build Roslyn, create a simple console application, include all the necessary DLL files, and write this code:
Run the app and get the following:
This Is Confusing
Let's say we agree with the nullable concept. It turns out that if we see the NR type, we assume that it may contain a potential null. However, sometimes we can stumble upon cases when the compiler tells us the opposite. Therefore, we'll walk through several cases where the use of this concept is not intuitive.Case 1
V3156 The first argument of the 'Concat' method is not expected to be null. Potential null value: bodyTokens. CSharpEditAndContinueAnalyzer.cs 219
First of all, we check out why bodyTokens is a potential null and notice the null conditional statement:
If we go inside the TryGetMethodDeclarationBody method, we will see that it can return null. However, it is relatively large, so I'm giving a link for you to see it for yourself. So, it's all clear with bodyTokens, but I'd like to point out the ctor argument:
As we can see, its type is set as NR. At the same time, here's a dereference in the line below:
This combination is a bit ominous. Nonetheless, you will say that, most likely, if IsKind returns true, then ctor is definitely not null. So it is:
Special attributes used here indicate at which output value the parameters will not be null. We can make sure of it by looking at the logic of the IsKind method. It turns out that the ctor type must be NNR inside the condition. The compiler is aware of it and says that the ctor inside the condition will not be null.
But if we want to get it ourselves, we have to go inside the IsKind method and notice the attribute there. Otherwise, it looks like dereferencing the NR variable without checking for null. We can try making this a bit more visible as follows:
V3156 The first argument of the 'LastIndexOf' method is not expected to be null. Potential null value: searchName. AbstractEditorInlineRenameService.SymbolRenameInfo.cs 126
We are interested in the searchName variable. null can be written into it after calling the GetWithoutAttributeSuffix method, but it's not that simple. Let's see what happens in it:
Let's dig a bit deeper:
It turns out that the TryGetWithoutAttributeSuffix method will return either result or null. The method returns the NR type. However, when we go back a step, we notice that the method type has suddenly changed to NNR. This is due to the hidden sign "!":
By the way, it is quite tricky to notice it in Visual Studio:
By setting it, the developer tells us that the method will never return null. Although looking at the previous examples and going into the TryGetWithoutAttributeSuffix method, I personally can't be sure:
In conclusion, I would like to note that the attempt to save us from unnecessary null checks is a great idea. However, NR types are rather advisory in nature, because no one strictly forbids us to pass null to the NNR type. Therefore, the corresponding PVS-Studio rules remain relevant. For example, such as V3080 or V3156.
All the best to you and thank you for your attention.
Published at DZone with permission of Nikolay Petkov, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.