3 issues: PREfast annotations in WDK 6001

I use WDK 6001 to build a user-mode app (this app was always built by DDK
since its very beginning 3 years ago).

Looks like PREfast annotations just plain do not work for such a build
(TARGETTYPE=library or TARGETTYPE=console).

Issue 1.

For instance, the documentation tells me to use __user_code; in this case.
__user_code is defined in driverspecs.h, which CANNOT be included to the
user-mode code for WDK builds, since this header file is in (WDK includes)\ddk
directory, and this directory is NOT in the include search path for the
user-mode WDK builds.

Issue 2.

More so. The __declspec("SAL_xxx") construct - like
__declspec("SAL_deref") - does not work!

It causes the "syntax error: string" compiler error. Looks like the
compiler lacks some command-line switch or some special definition in the
source to be capable of understanding the quoted string inside __declspec.

I have tried to create a trivial stupid C file and then build it using my
favourite "cl -MD -Ox file.c" command in the WDK's build env window without the
BUILD tool at all. Same result: __declspec("...") just cause _syntax_ error,
which do not care about what string is in the quotes.

What must I add to my SOURCES file for SAL annotations to work? once more -
this is user-mode code built by WDK.

Issue 3.

I have something like:

typedef struct _S
{
PUCHAR SomeData;
} S, *PS;

f(OUT S* sRet)
{
PS s;
s = (PS)MyAlloc(sizeof(S));
if( s == NULL ) fail;
s->SomeData = (PUCHAR)MyAlloc(SomeSize);
*sRet = s;
return OK;
}

and PREfast is showing me a warning 6014 about "s->SomeData" being leaked.
MyAlloc in this build is resolved to malloc.

How annotations can help to remove this warning? The code is valid and has
no memory leaks for years, being tested several times on a MFC-style debug
allocator (thus MyAlloc).

 

How about surrounding the "offensive" functions with #pragma
warning(disable:nnn)?

For example:

#pragma warning (push)
#pragma warning( disable:6014 ) // pacify warning 28250 in
PREfast
f(OUT S* sRet)
{
PS s;
s = (PS)MyAlloc(sizeof(S));
if( s == NULL ) fail;
s->SomeData = (PUCHAR)MyAlloc(SomeSize);
*sRet = s;
return OK;
}
#pragma warning (pop)


It worked for me. I hope that it works for you, too.

Don

 

How about surrounding the "offensive" functions with #pragma

Surely this last resort will work, but it breaks the very idea of SAL, so, I
would like to wait for other (MS's?) responses before going this way.

 

Prefast aside, IMO this is simply not a good coding practice even if we
assume the caller perfectly knows what it is doing (so I am not claiming
this is a bug per se).

The function returns non-NULL in two cases. Both when it could successfully
allocate memory for SomeData field and in the case when it couldn't. It may
very well be that caller is ok with allocating memory for the structure but
not SomeData but in all my years of coding I can't remember when I had to do
something like this and be ok with failing to allocate memory for SomeData.

Part of it could be that usually when I run into this situation (and I do
run into it a lot when I have to flatten a structure) I allocate only once
for both structure S and SomeData and set S->SomeData to S+1.

One thing I have to admit about prefast is that even though it has not found
that many real bugs in -my- code, it has forced me to be somewhat more
careful and clear.

-ali

 

The function returns non-NULL in two cases. Both when it could successfully

Surely the allocation failure on s->SomeData is handled and fails the whole
function, I just omitted it for brevity in the sample.

Nevertheless, PREfast says that s->SomeData is leaking.

Any ways except #pragma warning (disable) to get rid of this?

And now:

Issue 4.

typedef struct _S
{
// ...
FAST_MUTEX Lock;
} S, *PS;

// Must be called with s->Lock held, releases it within
VOID f(PS s)
{
// Some stuff done under the lock
ExReleaseFastMutex(&(s->Lock));
// Some stuff done outside the lock
}

Please suggest a way to annotate this perfectly valid code without #pragma
warning(disable).