I have hit the bogus static analysis error Scott described in his article last year:
Has anyone from OSR/MS got any feedback? If not, any thoughts on a workaround?
Thanks,
Ian.
IMHO there are many bogus errors in the latest versions of static analysis. I am still waiting for any kind of help from Microsoft on these issues. I suspect that they have paired back the compiler team after making a big investment leading up to VS 2015.
In my experience the compiler itself produces good binaries for x64 (probably others) but the SAL module only got to about 80%. Previously I made a like of the worst issues. There are others
- Static variables. These are never handled correctly by CA regardless of the scope of their declaration. If they are declared at function scope, then CA craps out on the remainder of the function. It may seem odd that this is even an issue, because just like goto many will say ?don?t do that? but static variables have some important usages especially in debug / trace code (I.e. call counts etc.) and I believe it is better to have the analysis on for every build to catch issues as early as possible ? which means running it with the trace code
- Flow of control based on multiple dependent variables. Where loop counters etc. are not independent variables are not independent, it is easy to observe many false positives for impossible array out of bounds conditions etc. Again it is easy to say, don?t do that, but for performance reasons it is often highly desirable to store a result from a previous loop or use a co-dependent set of counters. It seems clear that when evaluating the graph of every possible program state within a function, dependent variables are not considered concurrently but rather each variable is assumed to be independent ? a clear problem for false positives for codependent loop counters etc. but even worse a clear source of false negatives for aliased pointers.
- Reference tracking algorithms. Where in box from MS or home grown, the semantics are fundamentally not supported by SAL and so produce a long series of false positives and worse false negatives. The acquire routines work out okay, but the release routines are always a problem
- Locking annotations seem completely broken. I still annotate my functions because I want to understand the constraints, but I always get errors that I am completely unable to resolve
Sent from Mailhttps: for Windows 10
________________________________
From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
Sent: Tuesday, December 12, 2017 11:34:29 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Must succeed pool allocations are forbidden
I have hit the bogus static analysis error Scott described in his article last year:
https://www.osr.com/blog/2016/08/02/wdk-14393-code-analysis-enforces-pool_nx_optin-breaks-pool_nx_optin/
Has anyone from OSR/MS got any feedback? If not, any thoughts on a workaround?
Thanks,
Ian.
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></https:>
Thanks very much. Not quite the answer I was hoping for, but at least I’m aware of some more pitfalls now!