[cfe-dev] Fwd: [libc++] Should we guard against macro definitions
Marshall Clow via cfe-dev
cfe-dev at lists.llvm.org
Wed Sep 30 12:01:01 PDT 2015
forgot to cc the list on my reply.
---------- Forwarded message ----------
From: Marshall Clow <mclow.lists at gmail.com>
Date: Wed, Sep 30, 2015 at 11:58 AM
Subject: Re: [cfe-dev] [libc++] Should we guard against macro definitions
To: Ben Craig <ben.craig at codeaurora.org>
On Tue, Sep 22, 2015 at 9:44 AM, Ben Craig via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> 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)
That's not good enough, because we have to "hoist" the function into
> 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.
libc++'s <cmath> header does this for some of the calls there (look at
'fpclassify', for example).
Doing the same for cos (and others) shouldn't be too hard.
Can you provide a list of the functions that your library defines as macros?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev