On Wed, Oct 7, 2015 at 2:38 PM, Richard Smith <rich...@metafoo.co.uk> wrote:
> Marshall: ping, does the below satisfy your concerns about the direction
> here?
>
No, not really, because I'm worried about behavior changes with this
approach.
#include <ctype.h>
isdigit(c);
will call different code before and after this patch.
Before the patch, it will use the macro version.
After, it will use the built-in function.
However, since other standard libraries use this approach, this is probably
a baseless concern.
Assuming that my concerns are unfounded, the first six patches
(remove-macros, nullptr, ctype, errno and float) look fine to me.
Working on the rest.
-- Marshall
> On Wed, Sep 16, 2015 at 2:04 PM, Richard Smith <rich...@metafoo.co.uk>
> 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
