On Thu, Dec 10, 2015 at 5:24 PM, Duncan P. N. Exon Smith via cfe-commits < cfe-commits@lists.llvm.org> wrote:
> > On 2015-Dec-10, at 15:32, Richard Smith <rich...@metafoo.co.uk> wrote: > > > > On Thu, Dec 10, 2015 at 11:45 AM, Marshall Clow <mclow.li...@gmail.com> > wrote: > > On Tue, Dec 8, 2015 at 3:52 PM, Richard Smith <rich...@metafoo.co.uk> > wrote: > > Ping. > > > > Sorry about that. > > Completely missed this in my email flood. > > > > This approach looks ok to me, but I wonder if it would be better to get > Apple to fix their iOS C library instead. > > > > 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. > > > > Duncan offered to file a bug on this, but I don't know if that's > happened. > > Nope, I lost track of this. > > I just re-read the thread and I'm not clear on what bug I would even file > with the Libc folks. > > 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. > 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. This is the problem that Howard was bemoaning upthread. 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). > 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++?) > What other C standard libraries do (at least glibc, MSVC's libc, probably others) is to provide the C++ signatures when __cplusplus is defined.
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
