3 issues: PREfast annotations in WDK 6001

Discussion in 'Windows Vista Drivers' started by Maxim S. Shatskih, Mar 7, 2008.

  1. 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).
    Maxim S. Shatskih, Mar 7, 2008
    1. Advertisements

  2. Maxim S. Shatskih

    0dbell Guest

    How about surrounding the "offensive" functions with #pragma

    For example:

    #pragma warning (push)
    #pragma warning( disable:6014 ) // pacify warning 28250 in
    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. :)

    0dbell, Mar 7, 2008
    1. Advertisements

  3. 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.
    Maxim S. Shatskih, Mar 7, 2008
  4. 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.

    Alireza Dabagh [MS], Mar 8, 2008
  5. 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
    // Some stuff done outside the lock

    Please suggest a way to annotate this perfectly valid code without #pragma
    Maxim S. Shatskih, Mar 8, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.