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

[Marshall Clow via cfe-dev]

forgot to cc the list on my reply.

-- Marshall

---------- 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
namespace std.


>
>
> 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?

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