Taking into account what kind of method these are (from the names), my guess is that those are tricks to delay/prevent garbage collection of data or supress certain optimizations that would hide leaks.
It’s a seeming programmer error. The source code in question can be found here.
For IntPtr (also known as nint recently), null-checjking is supposed to be via comparison with IntPtr.Zero or the integer literal 0. Comparison to null (the language keyword) for IntPtr is incorrect, the way C# is designed, comparing a non-nullable struct instance to null without any operator overloading will always be false, so the net result is that the branch will never be taken. They even do this earlier in the file, which suggests someone came along and added stuff without understanding how to use IntPtr properly. If you see any bugs because of this, file a bug report.
Here’s a sharplab page with similar code as an example. You should see a warning about comparison with null. https://sharplab.io/#v2:CYLg1APgAgTAjAWAFBTgNgASwwYQwb2Q2K3SwBYMBZACgEkA7AFwAUmAnDANwEoCiSggJYAzDDS4YAvFIwMArgBtFfKAHYA3AMHFUAThoASAET4uAX2M8tSQeeTmgA==
Could just be leftovers-- I wrap code in if (false) { ... } all the time when I am in the middle of conducting some tests. I could comment it out, or block it out with directives, but I just find it easier to do this sometimes.
Example: if there’s already an if (condition) { code } block and I want to disable the whole thing, I just change it to if (false && condition) { code } while doing the test. If that code ships and someone decompiles it, they’ll just get the if (false) part or nothing at all, depending on the optimizer.
Thanks for pointing out. Looks like it’s a C++ to C# move leftover. It’s very common to compare pointer to null in c++, and both null pointer and null is actually integer zero.
Mystery solved.