[cfe-dev] Goal for 3.5: Library-friendly headers

[Alp Toker]

On 11/11/2013 19:08, Chris Lattner wrote:
> On Nov 11, 2013, at 9:56 AM, Alp Toker <alp at nuanti.com
> <mailto:alp at nuanti.com>> wrote:
>> Done :-)
>>
>> The patchset is 532K so I've put it online:
>>
>>   http://www.nuanti.com/tmp/llvm-api-stability/
>>
>> The bulk edits are split out and noted. They were refactored with an
>> internal tool, so it's not a big hassle to keep this up to date until
>> 3.4 is out the door.
>>
>> A handful of fixes were needed to add support for Release+Assert
>> builds and these are also separate commits.
>
> Whoa whoa whoa.  Why are you introducing an llvm_assert() macro?  The
> use of assert in header files is not a problem for "libraries", it is
> things like:
>
> #ifndef NDEBUG
>   int SomeNewVariable;
> #endif

They're both are a problem. assert() is defined deep down in the C
library headers and is conditional on !NDEBUG. It's not practical to
override the preprocessor define, at least with the MSVC and OS X
headers. (It _might_ be possible to hack around with glibc headers but
I'm not certain.)

That means that, as long as there are assert() uses in the headers and
you want to have a standard definition usable from a non-debug build,
you need a custom assert() macro.

Even when you have a !NDEBUG build, the platform assert() is pretty
crummy on Windows and generates, at best a UTF-16 dump, or sometimes
just pops up a dialog. WebKit and other projects take the same approach
and define their own assertion macros to deal with this portably.

So as far as I can tell, as long as the headers use assert(), they need
to use our own version in order for the definition to match.

Alp.


>
> in a class.
>
> -Chris
>

-- 
http://www.nuanti.com
the browser experts