Marshall, I think Richard has responded to your concerns. Anything left? This is blocking some things on our end.
On Wed, Sep 16, 2015 at 2:04 PM Richard Smith via cfe-commits < cfe-commits@lists.llvm.org> wrote: > On Mon, Sep 14, 2015 at 7:07 AM, Marshall Clow <mclow.li...@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). > _______________________________________________ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
