<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 8, 2015 at 6:27 AM, Marshall Clow <span dir="ltr"><<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Oct 7, 2015 at 2:38 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Marshall: ping, does the below satisfy your concerns about the direction here?</div></div></div></blockquote><div><br></div></span><div>No, not really, because I'm worried about behavior changes with this approach.</div><div><br></div><div> #include <ctype.h></div><div> isdigit(c);</div><div><br></div><div>will call different code before and after this patch.</div><div>Before the patch, it will use the macro version.</div></div></div></div></blockquote><div><br></div><div>That was non-conforming behaviour, per [headers]/6: </div><div><br></div><div> "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.]"</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>After, it will use the built-in function.</div><div><br></div><div>However, since other standard libraries use this approach, this is probably a baseless concern.</div><div><br></div><div>Assuming that my concerns are unfounded, the first six patches (remove-macros, nullptr, ctype, errno and float) look fine to me.</div><div><br></div><div>Working on the rest.</div><span class=""><font color="#888888"><div><br></div><div>-- Marshall</div></font></span><span class=""><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Sep 16, 2015 at 2:04 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Sep 14, 2015 at 7:07 AM, Marshall Clow <span dir="ltr"><<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">mclow.lists added a comment.<br>
<br>
I have two concerns about this patch (w/o commenting on the actual code).<br>
<br>
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.</blockquote><div><br></div></span><div>Yes, this is required by the C standard. C11 7.1.4/1 says:</div><div><br></div><div>"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.]"</div><span>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Have you checked other C libraries (Apple, FreeBSD, Android, Windows) to see if they also define both?</blockquote><div><br></div></span><div>No, but libstdc++ does the same #undef thing, so any platform it supports must have a non-broken C standard library.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote><div><br></div></span><div>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).</div></div></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>