8007770: fix name clash of assert macro in debug.hpp with libc's assert macro [Was: Re: Bug 100297 - [patch] fix name clash of assert macro in debug.hpp with libc's assert macro]

[Dean Long]

On 2/19/2013 6:44 PM, David Holmes wrote:
> On 20/02/2013 7:56 AM, Christian Thalinger wrote:
>> [David already filed an RFE for this:
>>
>> 8007770: fix name clash of assert macro in debug.hpp with libc's 
>> assert macro]
>
> Yes. For the record it is only undefined behaviour if you suppress the 
> assert macro and re-define it as a function - which we do not do.
>
> John Rose also added the following to the bug report:
>
> "I count about 15,000 occurrences of assert in our sources.
> The proposed rename would therefore be a disruptive change.
> Patches and change sets would no longer apply across that change, 
> leading to maintenance costs, especially back-porting bug fixes.
> Thus, a mere claim of "would be prudent to conform exactly to the 
> standard" is not enough grounds to accept this change.
>
> Since 'assert' macros are common programming practice, we can expect 
> (or request, if necessary) that the C++ standard libraries provide an 
> op-out mechanism, such as '#undef assert' or '-DNDEBUG'.
>
> For a reference on NDEBUG, see: 
> http://www.cplusplus.com/reference/cassert/assert/
>
> (To be clear, NDEBUG does not remove the macro. Another option would 
> be required, if #undef is not allowed.) "
>
> ---
>
> If this is potentially a problem then I think we need to avoid it by 
> other means - most likely by bracketing standard includes with "#undef 
> assert" so that they are not affected by hotspot's definition, and our 
> source is not affected by the definition from assert.h
>

Can't we just do something like the following in debug.hpp?

#include <assert.h>
#undef assert
#define assert(p, msg) \
...

Any #include <assert.h> that happens after this should be a no-op 
because it was already included once.

dl

> David
> -----