[cfe-dev] [libc++] Should we guard against macro definitions

[Ben Craig via cfe-dev]

I have a C library, and I want to build libc++ and libc++abi against it.
This C library's implementation of many of the math.h functions involves
code similar to.

#define cos(Val) RealCosImpl(Val)

 

This interacts poorly with libcxx's cmath header, as the float and long
double overload declarations hit this #define.

 

If I make a patch that guards the bulk of cmath from this kind of macro, do
people feel that this would be useful, or would it get rejected on the
grounds that it is unnecessary noise to support an odd C library?  This fix
would generally take the form of putting the function name in parenthesis to
suppress function macro expansion.  So code that looks like this. 

float cos(float val)

. would turn into this.

float (cos)(float val)

 

One could argue that this would be a reasonable thing to do across libcxx,
but I think it is more important to do so for cmath, as many of those
functions must have macro version in the C tgmath.h header (but not the C++
one).  It probably wouldn't hurt to throw some parenthesis at std::min and
std::max in <algorithm> as well, considering the unfortunate history with
those and the <windows.h> min and max macros.

 

Employee of Qualcomm Innovation Center, Inc.

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150922/c4418d79/attachment.html>