_Outptr_result_maybenull_ and variants interpreted incorrectly

[kennykerr]

Like a few previous issues, this SAL annotation denotes that the result may be null, not that the parameter itself is optional. For example, ID2D1DeviceContext::GetTarget is described as follows:

unsafe void GetTarget([Optional][Out] ID2D1Image* image);

But this parameter is not in fact optional. There are also plenty of other parameters with these annotations being interpreted incorrectly. These include:

• _Outptr_result_maybenull_
• _Outptr_result_buffer_maybenull_
• _COM_Outptr_result_maybenull_

There may well be others.

[kennykerr]

From sal.h:

   Nullness:
   --------
   If the parameter can be NULL as a precondition to the function, the
   annotation contains _opt. If the macro does not contain '_opt' the
   parameter cannot be NULL.

   If an out/inout parameter returns a null pointer as a postcondition, this is
   indicated by _Ret_maybenull_ or _result_maybenull_. If the macro is not
   of this form, then the result will not be NULL as a postcondition.
     _Outptr_ - output value is not NULL
     _Outptr_result_maybenull_ - output value might be NULL

[AArnott]

This would help microsoft/CsWin32#130 as well

[kennykerr]

XmlLite's IXmlReader is another good example.

[kennykerr]

IUriBuilder is another example. Is there anything we can do in the short term to start catching some of these? Even if we just detect _Outptr_result_maybenull_ as not being optional. This is just really hurting the calling experience.

[kennykerr]

Thanks! Can you publish another build and I'll take it for a spin.

[mikebattista]

Yes it's published now.

[kennykerr]

Thanks!