Ticket #2115 Avoid bad Apple macros
Apple has a header called <AssertMacros.h> that #defines both “check” and “check_error.” These macros naturally collide with the same names in Boost. We should consider a global change.
What global change? That Boost not use these names? What about the other horrid macros in that header? Here is a list from Marshall: debug_string, check, ncheck, check_string, ncheck_string, check_noerr, check_noerr_string, verify, nverify, verify_string, nverify_string, verify_noerr, verify_noerr_string, verify_action, require, nrequire, require_action, nrequire_action, require_quiet, nrequire_quiet, require_action_quiet, nrequire_action_quiet, require_string, nrequire_string, requireaction_string, nrequireaction_string, require_noerr, require_noerr_action, require_noerr_quiet, require_noerr_action_quiet, require_noerr_string, require_noerr_action_string. Marshall comments: IMHO, the really nasty ones are: check, verify, require and check_error.
That would also probably require a global policy change for checkins.
Assigning to Beman, Cc'ing John M, component "inspection script" assigned to John although I might be wrong about that, but obviously we need to discuss this. Maybe we'll decide to make it "wontfix"
I really don't want to start a policy of avoiding every name that is defined in any vendor header. I forget the details, but at least one vendor has shipped a header defining "read" and "write" macros! The fix for this one is to complain to Apple. They need to provide a new new header that supplies the functionality but using macro naming discipline, deprecate the old header, and add a warning to the old header suggesting that users migrate to the new header. If they wanted to be really helpful, they could provide a script to automatically change the old names to the new names. And if they have any other headers that fail to apply macro naming discipline, they should do the same for those headers too. By "naming discipline", I mean something like the Boost policy for macro names always being all uppercase and beginning with BOOST_. --Beman
On Oct 11, 2008, at 8:59 AM, Beman Dawes wrote:
Apple has a header called <AssertMacros.h> that #defines both “check” and “check_error.” These macros naturally collide with the same names in Boost. We should consider a global change.
What global change? That Boost not use these names?
What about the other horrid macros in that header? Here is a list from Marshall:
debug_string, check, ncheck, check_string, ncheck_string, check_noerr, check_noerr_string, verify, nverify, verify_string, nverify_string, verify_noerr, verify_noerr_string, verify_action, require, nrequire, require_action, nrequire_action, require_quiet, nrequire_quiet, require_action_quiet, nrequire_action_quiet, require_string, nrequire_string, requireaction_string, nrequireaction_string, require_noerr, require_noerr_action, require_noerr_quiet, require_noerr_action_quiet, require_noerr_string, require_noerr_action_string.
Marshall comments: IMHO, the really nasty ones are: check, verify, require and check_error.
That would also probably require a global policy change for checkins.
Assigning to Beman, Cc'ing John M, component "inspection script" assigned to John although I might be wrong about that, but obviously we need to discuss this. Maybe we'll decide to make it "wontfix"
I really don't want to start a policy of avoiding every name that is defined in any vendor header. I forget the details, but at least one vendor has shipped a header defining "read" and "write" macros!
The fix for this one is to complain to Apple. They need to provide a new new header that supplies the functionality but using macro naming discipline, deprecate the old header, and add a warning to the old header suggesting that users migrate to the new header. If they wanted to be really helpful, they could provide a script to automatically change the old names to the new names. And if they have any other headers that fail to apply macro naming discipline, they should do the same for those headers too. By "naming discipline", I mean something like the Boost policy for macro names always being all uppercase and beginning with BOOST_.
How is <AssertMacros.h> being included? I'm assuming indirectly through some standard header, but I'm not sure which one. Is there a HelloWorld demo? Thanks, Howard
Apple has a header called <AssertMacros.h> that #defines both "check" and "check_error." These macros naturally collide with the same names in Boost. We should consider a global change.
What global change? That Boost not use these names?
What about the other horrid macros in that header? Here is a list from Marshall:
[ list containing about 60 names elided ]
Marshall comments: IMHO, the really nasty ones are: check, verify, require and check_error.
That would also probably require a global policy change for checkins.
Assigning to Beman, Cc'ing John M, component "inspection script" assigned to John although I might be wrong about that, but obviously we need to discuss this. Maybe we'll decide to make it "wontfix"
I really don't want to start a policy of avoiding every name that is defined in any vendor header. I forget the details, but at least one vendor has shipped a header defining "read" and "write" macros!
The fix for this one is to complain to Apple. They need to provide a new new header that supplies the functionality but using macro naming discipline, deprecate the old header, and add a warning to the old header suggesting that users migrate to the new header. If they wanted to be really helpful, they could provide a script to automatically change the old names to the new names. And if they have any other headers that fail to apply macro naming discipline, they should do the same for those headers too. By "naming discipline", I mean something like the Boost policy for macro names always being all uppercase and beginning with BOOST_.
[ sorry for the excessive quoting, but I think the context is important ] While I agree with Beman (complain to Apple), and Howard has filed a bug report with Apple, that still leaves us hurting at the present time. I think a good workaround is to define __ASSERTMACROS__ in the darwin jam file, which will disable all those macros (by preventing /usr/include/AssertMacros.h from being parsed), and mentioning it in the docs. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
On Sat, Oct 11, 2008 at 5:59 AM, Beman Dawes <bdawes@acm.org> wrote:
Apple has a header called <AssertMacros.h> that #defines both "check" and "check_error." These macros naturally collide with the same names in Boost. We should consider a global change.
What global change? That Boost not use these names?
[snip]
I really don't want to start a policy of avoiding every name that is defined in any vendor header. I forget the details, but at least one vendor has shipped a header defining "read" and "write" macros!
Unfortunately, this isn't a corner case of some obscure name in an obscure vendor header. This header gets #included in mainstream use cases.
The fix for this one is to complain to Apple. [snip]
I am a library provider. My library depends on boost. Clients of my library are also clients of boost. Some of my clients may wish to use the Apple macros. If boost code fails to work in the presence of an Apple of Microsoft header, I must patch boost. (This is why, unpleasant as it is, my code myst compile without defining NOMINMAX. Of course it is important to file bugs and put pressure on vendors when they stray. But first I must produce a library that works in my clients' environments.) Similarly, i boost code emits a warning and my client wants to treat warnings as errors, I must patch boost. If any boost code has 64-bit runtime issues, or fails to work in a DLL, I must patch it. So, please put pressure on Apple, and file the necessary bug reports. But each requirement that a library imposes loses a group of users. But please also consider "fixing" boost too. - Mat
On Sun, Oct 12, 2008 at 2:30 PM, Mat Marcus <mat-lists@emarcus.org> wrote: ...
So, please put pressure on Apple, and file the necessary bug reports. But each requirement that a library imposes loses a group of users. But please also consider "fixing" boost too.
I still haven't seen a concrete proposal as to exactly what a fix would be. If it is something that has no effect on users of other platforms, that's one thing. Boost has lots of workarounds for platform specific deficiencies that only kick in on those platforms. But if a "fix" is something that impacts all boost users and developers on all platforms, my level of concern goes way up. So a specific proposal for a fix would be appreciated. --Beman
On Sun, Oct 12, 2008 at 1:54 PM, Beman Dawes <bdawes@acm.org> wrote:
On Sun, Oct 12, 2008 at 2:30 PM, Mat Marcus <mat-lists@emarcus.org> wrote: ...
So, please put pressure on Apple, and file the necessary bug reports. But each requirement that a library imposes loses a group of users. But please also consider "fixing" boost too.
I still haven't seen a concrete proposal as to exactly what a fix would be.
Sadly, I don't know of a better fix than the one you mentioned at the beginning of this thread--namely, that boost avoid using the names that vendors steal with macros in commonly included headers. I didn't like having to rename functions named check() in our code, but my users like it even less when things didn't work for them. (This was some time ago...I didn't look at the original bug report, and I don't know how many Apple headers still pull the offending header in indirectly).
Mat Marcus wrote:
On Sun, Oct 12, 2008 at 1:54 PM, Beman Dawes <bdawes@acm.org> wrote:
On Sun, Oct 12, 2008 at 2:30 PM, Mat Marcus <mat-lists@emarcus.org> wrote: ...
So, please put pressure on Apple, and file the necessary bug reports. But each requirement that a library imposes loses a group of users. But please also consider "fixing" boost too.
I still haven't seen a concrete proposal as to exactly what a fix would be.
Sadly, I don't know of a better fix than the one you mentioned at the beginning of this thread--namely, that boost avoid using the names that vendors steal with macros in commonly included headers. I didn't like having to rename functions named check() in our code, but my users like it even less when things didn't work for them. (This was some time ago...I didn't look at the original bug report, and I don't know how many Apple headers still pull the offending header in indirectly).
Are the Apple defined macros function-like macros? If so we could use the usual macro-expansion suppression in these cases as we do with min/max. John.
On Mon, Oct 13, 2008 at 1:40 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Mat Marcus wrote:
On Sun, Oct 12, 2008 at 1:54 PM, Beman Dawes <bdawes@acm.org> wrote:
On Sun, Oct 12, 2008 at 2:30 PM, Mat Marcus <mat-lists@emarcus.org> wrote: ...
So, please put pressure on Apple, and file the necessary bug reports. But each requirement that a library imposes loses a group of users. But please also consider "fixing" boost too.
I still haven't seen a concrete proposal as to exactly what a fix would be.
Sadly, I don't know of a better fix than the one you mentioned at the beginning of this thread--namely, that boost avoid using the names that vendors steal with macros in commonly included headers. I didn't like having to rename functions named check() in our code, but my users like it even less when things didn't work for them. (This was some time ago...I didn't look at the original bug report, and I don't know how many Apple headers still pull the offending header in indirectly).
Are the Apple defined macros function-like macros? If so we could use the usual macro-expansion suppression in these cases as we do with min/max.
John.
Yes, at least check is function-like: #define check(assertion) \ do \ { \ if ( __builtin_expect(!(assertion), 0) ) \ { \ DEBUG_ASSERT_MESSAGE( \ DEBUG_ASSERT_COMPONENT_NAME_STRING, \ #assertion, \ 0, \ 0, \ __FILE__, \ __LINE__, \ 0); \ } \ } while ( 0 )
On Mon, 13 Oct 2008 09:40:33 +0100, "John Maddock" <john@johnmaddock.co.uk> wrote:
Are the Apple defined macros function-like macros? If so we could use
the
usual macro-expansion suppression in these cases as we do with min/max.
Yeah, just as long as we keep in mind that the parens suppress ADL. In other words check(x) and (check)(x) are not equivalent. -- David Abrahams Boostpro Computing http://www.boostpro.com
David Abrahams wrote:
"John Maddock" <john@johnmaddock.co.uk> wrote:
Are the Apple defined macros function-like macros? If so we could use the usual macro-expansion suppression in these cases as we do with min/max.
Yeah, just as long as we keep in mind that the parens suppress ADL. In other words
check(x)
and
(check)(x)
are not equivalent.
I think John is referring to the BOOST_PREVENT_MACRO_SUBSTITUTION macro: check BOOST_PREVENT_MACRO_SUBSTITUTION (x) -- Eric Niebler BoostPro Computing http://www.boostpro.com
Heh, I forgot about that one. Suppose we just #define check BOOST_PREVENT_MACRO_SUBSTITUION check ? ;-) Sent from my iPhone On Oct 13, 2008, at 11:51 PM, Eric Niebler <eric@boost-consulting.com> wrote:
David Abrahams wrote:
"John Maddock" <john@johnmaddock.co.uk> wrote:
Are the Apple defined macros function-like macros? If so we could use the usual macro-expansion suppression in these cases as we do with min/max. Yeah, just as long as we keep in mind that the parens suppress ADL. In other words check(x) and (check)(x) are not equivalent.
I think John is referring to the BOOST_PREVENT_MACRO_SUBSTITUTION macro:
check BOOST_PREVENT_MACRO_SUBSTITUTION (x)
-- Eric Niebler BoostPro Computing http://www.boostpro.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Steven Watanabe wrote:
Heh, I forgot about that one. Suppose we just
#define check BOOST_PREVENT_MACRO_SUBSTITUION check
? ;-)
Won't that cause macro redefinition errors? Also, how is it different from
#define check check
In fact it's not really any different from: #undef check is it? John.
on Tue Oct 14 2008, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
Steven Watanabe wrote:
Heh, I forgot about that one. Suppose we just
#define check BOOST_PREVENT_MACRO_SUBSTITUION check
? ;-)
Won't that cause macro redefinition errors? Also, how is it different from
#define check check
In fact it's not really any different from:
#undef check
is it?
Programmers are such literalists. I assumed you would not take that suggestion seriously, given the winky. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (8)
-
Beman Dawes -
David Abrahams -
Eric Niebler -
Howard Hinnant -
John Maddock -
Marshall Clow -
Mat Marcus -
Steven Watanabe