Microsoft's SAL Deref=1 property in relation to an “int” parameter?

Question

I've come round to the idea that Microsoft's SAL (Source Annotation Language) is a good thing, and have studied the language and the meaning of annotation properties .

I have a general question about the use of SAL's " Deref " property in connection with an " int " parameter. Let me illustrate my question with the SAL for the isalpha() function, taken from the ctype.h include file, running Visual Studio 10:

[returnvalue:SA_Post(MustCheck=SA_Yes)] int __cdecl isalpha([SA_Pre(Null=SA_No)] [SA_Pre(Deref=1,Valid=SA_Yes,Access=SA_Read)] int _C);

If the single parameter _C is an " int ", what does "[SA_Pre( Deref=1 ,Valid=SA_Yes,Access=SA_Read)]" mean? How can one dereference an int once (Deref=1) in a meaningful way?

The only explanation I can think of is that the annotation states that the integer is a reference into ctype's internal byte array. How could a static analyzer take advantage of this annotation?

Answer 1

What it looks like is that you've pasted in the pre-processed version of the isalpha declaration. What I see in ctype.h is:

_Check_return_ _CRT_JIT_INTRINSIC _CRTIMP int __cdecl isalpha(_In_ int _C);

_In_ is allowed on scalar parameters (int, etc.) in order to let developers explicitly express that the parameter is strictly an input parameter. This is kind of redundant, but still true (after all, you can't return a value via a pass-by-value scalar).

The annotation _In_ is a macro that expands as you've pasted above in order to express the semantics of an input pointer . The static analyzer recognizes when _In_ is being applied to a scalar parameter and ignores it, since neither the Null nor the Deref=1 makes much sense on an int.

In any other context, besides being part of an _In_ annotation, Deref=1 on an int would make no sense.

It's generally better to be using the _In_ -style syntax rather than the SA_Pre and SA_Post, unless you really want to be looking into the underlying implementation details like this.