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

[Richard Smith via cfe-commits]

On Thu, Oct 8, 2015 at 6:27 AM, Marshall Clow <mclow.lists at gmail.com> wrote:

> On Wed, Oct 7, 2015 at 2:38 PM, Richard Smith <richard at 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.
>

That was non-conforming behaviour, per [headers]/6:

  "Names that are defined as functions in C shall be defined as functions
in the C++ standard library. [Footnote: This disallows the practice,
allowed in C, of providing a masking macro in addition to the function
prototype.]"

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 <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/20151008/d63c00dc/attachment.html>