0

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?

Moshe Rubin
  • 1,944
  • 1
  • 17
  • 37

1 Answers1

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.

DavidS
  • 2,904
  • 1
  • 15
  • 21
  • I only noticed your reply now, but there's no statute of limitations on saying thank you . – Moshe Rubin Jan 09 '12 at 12:29
  • You're perfectly right that one should use SAL at its highest semantic level. In my case I need to parse and understand the SAL preprocesser output. Your answer is reassuring: there may be redundant infor, but a static analyzer worth its salt will ignore that information. BTW, MS CRT functions use attribute SAL while the Win32 functions use declspec SAL, so one might need to learn both dialects (see [link](http://blogs.msdn.com/b/sdl/archive/2009/06/11/a-declspec-sal-to-attribute-sal-rosetta-stone.aspx)). – Moshe Rubin Jan 09 '12 at 12:49
  • Glad it was useful! If you think it's worth it, please mark the answer as accepted. And I'd also note that the Win32 functions are moving to the MS CRT style syntax (e.g. _In_ rather than __in) for Windows 8. – DavidS Jan 14 '12 at 06:06