On Thu, Oct 8, 2015 at 6:27 AM, Marshall Clow <mclow.li...@gmail.com> wrote:
> 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. > 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 <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
