[PATCH] D12747: Implement [depr.c.headers]

[Richard Smith via cfe-commits]

Marshall: ping, does the below satisfy your concerns about the direction
here?

On Wed, Sep 16, 2015 at 2:04 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

> On Mon, Sep 14, 2015 at 7:07 AM, Marshall Clow <mclow.lists at gmail.com>
> wrote:
>
>> mclow.lists added a comment.
>>
>> I have two concerns about this patch (w/o commenting on the actual code).
>>
>> 1. Until very recently, I was under the impression that C libraries
>> _either_ defined a macro, or had a function. I was quite surprised to find
>> that glibc did both.
>
>
> Yes, this is required by the C standard. C11 7.1.4/1 says:
>
> "Any function declared in a header may be additionally implemented as a
> function-like macro defined in the header [...]. 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.]"
>
> Have you checked other C libraries (Apple, FreeBSD, Android, Windows) to
>> see if they also define both?
>
>
> No, but libstdc++ does the same #undef thing, so any platform it supports
> must have a non-broken C standard library.
>
>
>> 2. This adds a lot of header files. Each header file slows down
>> compilation, and standard library header files get included *a lot*. We may
>> not be able to avoid this, but we should think about the costs here.
>
>
> I created a .cpp file that includes all of the <*.h> headers and does
> nothing else (which should maximize the performance difference), and built
> it with and without this change. I could not measure any difference (the
> average compile time with this change was slightly lower, but that is
> almost certainly noise).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151007/38989f78/attachment.html>