Evil macros in April 2005 Platform SDK headers

I’m upgrading one of my build machines to use the April 2005 edition of the Platform SDK to investigate the implications of this posting over at eggheadcafe.com which states that since Visual Studio 6 ceased to be supported as of the end of September 2005 the last version of the Platform SDK that will work with Visual Studio 6 was the February 2003 version.

There has been quite a lot of discussion in the comments of my Bluetooth code sample about the ‘broken’ uuid.lib file in the later Platform SDKs. I thought it was just a corrupted lib file but it seems that it’s by design. So it seems I should investigate as I still have some clients using Visual Studio 6…

The first problem I’ve discovered is that the latest SDK defines lots of new macros which live in the file specstrings.h. These are part of special buffer overflow checking annotations that Visual Studio 2005 can use to check your code for hard to find bugs as it compiles. The annotations are explained here over on Martyn Lovell’s blog, Constructopaedia. Whilst the intention is good the implementation is less so due to the evils of macros.

The macros that are currently causing me concern are __in and __out. These clash with identifiers used in STLPort and the way that the macros are conditionally enabled means that the STLPort identifiers are defined to nothing and this breaks the compile.

Given the macros start with a double underscore and the C++ standard says that: "[…] identifiers containing a double underscore (__) […] are reserved for use by C++ implementations and standard libraries and shall be avoided by users; no diagnostic is required." you could say that Microsoft are in the right here, they’re allowed to use double underscores and nobody else is. Well, I guess that depends on whether you include STL as a standard library or not… In fact, if you look up “C++ keywords” in MSDN, you’ll see that Microsoft read that paragraph slightly differently; they see it as saying: “In Microsoft C++, identifiers with two leading underscores are reserved for compiler implementations.”

Either way STLPort’s use of double underscores is mostly restricted to variables that are, at the very least, namespaced so that they’re unlikely to clash with user code and user code shouldn’t be using double underscores anyway. The Microsoft macros just trample over everything in their path. Of course there isn’t really a way to avoid using macros for this kind of thing and the Windows headers are already full of defines that sometimes clash with C++ code (min and max, for example…). I guess it’s highly unlikely that Microsoft will rename these, and all their macros to something that attempts to “namespace” them to the compiler or to Windows, or whatever __MS_in ?

At least the fix to STLPort is reasonably simple in this case…