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

Richard Smith via cfe-commits cfe-commits at lists.llvm.org
Wed Sep 16 14:04:09 PDT 2015


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/20150916/e560c672/attachment.html>


More information about the cfe-commits mailing list