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

[Alp Toker]

On 10/11/2013 14:26, Joerg Sonnenberger wrote:
> On Sun, Nov 10, 2013 at 01:42:24PM +0000, Alp Toker wrote:
>> |#undef NetBSD||
>> ||#undef mips||
>> ||#undef sparc||
>> ||#undef INT64_MAX||
>> ||#undef alloca|
>>
>> This is not OK to do globally -- even if LLVM doesn't care about the
>> definition, maybe embedding applications or OS headers do?
> Given that 3 of the 5 #undefs are directly relevant for me -- they exist
> because OS headers and/or compiler default configurations provide legacy
> macros that can't easily be dropped without breaking old cruft. All
> modernish software is supposed to use the corresponding __ version of
> the names.

Library design means thinking about these things:

1) Not using compiler-predefined macro names as identifiers in headers:
If it's known for a fact that GCC defines some name on a platform we
care about, it's likely that some OS or application header somewhere
depends on it. Undefining, especially out of order as in Triple.h, isn't
a solution. If you know about these three, then great, we already found
someone who can implement the correct fix ;-)

2) Not making declarations conditional on NDEBUG or other
configuration-specific defines, including compiler features: Right now,
if you have a release build of LLVM and using the C++ interface, you
have to build your own application with NDEBUG.

These should certainly interest people who've tried embedding LLVM in
non-trivial external applications.

The subtext here, of course, is that this may even go some way to
providing access from non-C++11 compilers for some amount of time after
the first C++11 features start to land in the 3.5 series.

It'll be interesting to see who's willing step up and help here with
patches, as opposed to just being in the "me too" crowd who post to the
list.

Alp.


>
> INT64_MAX as seen by the context is about a AIX specific header bug.
>
> alloca has a comment about VC++. Might be better to add a conditional
> around it and see if that solves the problem.
>
> In short, I don't see a real problem here.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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