<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 10, 2015 at 5:24 PM, Duncan P. N. Exon Smith via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On 2015-Dec-10, at 15:32, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
><br>
> On Thu, Dec 10, 2015 at 11:45 AM, Marshall Clow <<a href="mailto:mclow.lists@gmail.com">mclow.lists@gmail.com</a>> wrote:<br>
> On Tue, Dec 8, 2015 at 3:52 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> Ping.<br>
><br>
> Sorry about that.<br>
> Completely missed this in my email flood.<br>
><br>
> This approach looks ok to me, but I wonder if it would be better to get Apple to fix their iOS C library instead.<br>
><br>
> Well, it's not broken in the sense that it does what the C standard library is supposed to do. But it's not providing the "C pieces" of a C++ standard library. I don't know what its design goal is here, but with this patch we don't need to care.<br>
><br>
> Duncan offered to file a bug on this, but I don't know if that's happened.<br>
<br>
</span>Nope, I lost track of this.<br>
<br>
I just re-read the thread and I'm not clear on what bug I would even file with the Libc folks.<br>
<br>
Darwin's implementation of the string.h C header seems to match what n1570's 7.24.5.2 The strchr function asks for.  That's not the right thing for n3337's 21.7 Null-terminated sequence utilities, but that does seem like a problem for libc++ to solve.<br></blockquote><div><br></div><div>Here's the rub: that problem is impossible for a C++ standard library to solve, assuming that its <std*.h> includes the underlying C <std*.h>, and it doesn't use any non-portable extension (beyond something like #include_next) nor assume that it knows the exact implementation details of the C library.</div><div><br></div><div>This is the problem that Howard was bemoaning upthread.</div><div><br></div><div>I suppose if we apply the patch in this thread, then recent Clang + recent libc++ + Darwin's libc will provide the right signatures, and if that's the only configuration you guys care about going forward then there's no bug for you to fix. But that's a decision for Apple to make, not us. In any case, this patch fixes the corresponding problem in other libc implementations that don't provide the C++ signatures (such as musl libc).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm probably missing the point somehow though.  If you can clarify exactly what should be different in Libc (whether or not it's a bug in C), I can ask around and find out how likely it is to get fixed.  (What does GCC do here that it's not a problem over there?  Provide different signatures depending on whether the caller is C or C++?)<br></blockquote><div><br></div><div>What other C standard libraries do (at least glibc, MSVC's libc, probably others) is to provide the C++ signatures when __cplusplus is defined. </div></div></div></div>