There is a thread going on in the newsgroups (following a previous discussion on NTDEV) pointing out a current compiler bug in the DDK relating to the return value of InterlockedOr(). As Gary Little pointed out, it’s not a commonly used function, particularly when it comes to examining the return value, but nevertheless, the bug is there, so you should be aware of it.
Elyias Yakub from Microsoft pointed out that the bug had been reported and fixed a couple of years ago in the mainline compilers, and another poster mentioned that the Visual C++ 2005 compiler doesn’t exhibit this problem.
The bug is in the compiler intrinsic, so don’t try to bypass the API by going to the intrinsic – you’ll have the same problem. If you do call InterlockedOr(), treat it as returning VOID – don’t check the return value.
And while the bug may be fixed in the WDK compiler (I haven’t checked, actually), that is still a beta kit so it’s still subject to change. If you do wind up needing this DDI, you should probably hand-verify the generated code.
[...] According to some folks on USENET, it’s not just InterlockedOr() that’s broken (see my earlier post for background). [...]
[...] Mark Lacey, a developer who works on the compilers and related tools, has a great blog post up with a definitive explanation of the Interlocked* code generation issue that I mentioned before. He left a comment linking to his post, but I thought I’d link it from the main page since I did complain about this issue on the main page. [...]