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

[Richard Smith via cfe-dev]

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

If you're not providing a declaration of a real 'cos' function, you do not
have a conforming C standard library. See C11 7.1.4/1:

"Any function declared in a header may be additionally implemented as a
function-like macro defined in the header, so if a library function is
declared explicitly when its header is included, one of the techniques
shown below can be used to ensure the declaration is not affected by such a
macro. Any macro definition of a function can be suppressed locally by
enclosing the name of the function in parentheses, because the name is then
not followed by the left parenthesis that indicates expansion of a macro
function name. For the same syntactic reason, it is permitted to take the
address of a library function even if it is also defined as a macro.
[Footnote: This means that an implementation shall provide an actual
function for each library function, even if it also provides a macro for
that function.]"

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

We should just fix this with

#undef cos

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
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150930/fc104dd9/attachment.html>