Fix collision with Apple macros?

183 views
Skip to first unread message

Nils Barth

unread,
May 9, 2014, 8:17:50 AM5/9/14
to blink-dev, Dirk Pranke, Nico Weber
Apple defines macros in AssertMacros.h that collide with everyday words, notably require and verify (!).
This requires avoiding these words in code; I saw this problem in modules/SubtleCrypto, which has to avoid "verify" from the IDL spec.

As of Mac OS 10.6, this can be fixed by adding a preprocessor define in the code as:
#define __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES 0
...or at the command line as:
-D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0

I assume this is still a problem, as I don't see this defined in the tree; could we add this define to (Mac) build?

Quoting from AssertMacros.h:

 * For time immemorial, Mac OS X has defined version of most of these macros without the __ prefix, which * could collide with similarly named functions or macros in user code, including new functionality in * Boost and the C++ standard library. * * A future release of Mac OS X will no longer do this, and will require that clients move to the * new macros as defined above. However, in the interim both the new and old macros will work, unless * clients define a macro __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES before this file is included * in their compilations. Clients who do not want the older macros defined can accomplish this by adding * #define __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES 0 * at the top of their sources, or my adding -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0 to the * gcc compilation options.

Dirk Pranke

unread,
May 9, 2014, 11:00:54 AM5/9/14
to Nils Barth, blink-dev, Nico Weber, Robert Sesek, Mark Mentovai
Seems plausible to me, but I'm no Mac expert. Adding +rsesek and +mark who are (in addition to Nico) ...

-- Dirk

Mark Mentovai

unread,
May 9, 2014, 11:40:37 AM5/9/14
to Dirk Pranke, Nils Barth, blink-dev, Nico Weber, Robert Sesek
I think this is OK. What’s another #define in the sea of macros we already have?

Ironically, the one and only system header that #includes AssertMacros.h is CoreServices/CarbonCore/Debugging.h, and it defines macros that depend on the un-underscored names. Defining this __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORE=0 will break the use of those Debugging.h macros (the *tasklevel0* macros), but nobody uses them anyway. These umbrella framework includes bring in a lot of stuff (like AssertMacros.h) that nobody’s using.
Reply all
Reply to author
Forward
0 new messages