{"id":404055,"date":"2024-06-29T17:29:11","date_gmt":"2024-06-29T17:29:11","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=404055"},"modified":"-0001-11-30T00:00:00","modified_gmt":"2024-06-29T17:29:11","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=404055","title":{"rendered":"Nullable Reference will not protect you, and here is the proof<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n
\"image1.png\"<\/div>\n

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.
<\/a>
We warned you, and it happened. About a year ago, my colleagues wrote an article<\/a> in which they warned that the introduction of Nullable Reference types will not protect against dereferencing null references. Now we have an indisputable proof of what we were saying found in the depths of Roslyn.<\/p>\n

Nullable Reference types<\/h2>\n

The idea itself of adding Nullable Reference<\/i> (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<\/i> value. For example, a variable of the string?<\/i> type indicates that it might contain null<\/i>, and a variable of the string<\/i> type might imply the opposite <\/p>\n

However, nobody’s stopping us from passing null<\/i> to non-nullable reference<\/i> variables (further as \u2014 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:<\/p>\n

#nullable enable object? nullable = null; object nonNullable = nullable; var deref = nonNullable.ToString();<\/code><\/pre>\n
  As we can see, the nonNullable<\/i> type is specified as NNR, but we can safely pass null<\/i> 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 round it a bit more aggressively:<\/p>\n
#nullable enable object? nullable = null; object nonNullable = nullable!; \/\/ <= var deref = nonNullable.ToString();<\/code><\/pre>\n
  One exclamation mark and there are no warnings. If you’re a nitpicker, the following option is also available:<\/p>\n
#nullable enable object nonNullable = null!; var deref = nonNullable.ToString();<\/code><\/pre>\n
  Here’s another example. Let’s create two simple console projects. In the first we write:<\/p>\n
namespace NullableTests {     public static class Tester     {         public static string RetNull() => null;     } }<\/code><\/pre>\n
  In the second one we write:<\/p>\n
#nullable enable   namespace ConsoleApp1 {     class Program     {         static void Main(string[] args)         {             string? nullOrNotNull = NullableTests.Tester.RetNull();             System.Console.WriteLine(nullOrNotNull.Length);         }     } }<\/code><\/pre>\n
  Hover the cursor over nullOrNotNull<\/i> and see this message:<\/p>\n
\"image2.png\"<\/div>\n
  It’s a hint that the string here can’t be null<\/i>. But we already know that it will be null<\/i> right here. Run the project and get the exception:<\/p>\n
\"image3.png\"<\/div>\n
  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 \u2014 they will be further in the article.<\/p>\n
  NR types also have another problem \u2014 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 nullable context is enabled in a project or file. Otherwise, you might mistakenly assume that the normal reference type is NNR.<\/p>\n
How we found proofs <\/h2>\n
  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: <\/p>\n