> 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. 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++?) > Are there other broken C libraries that we are concerned with? > > Probably :) I don't know the complete set of C standard library > implementations that people use with libc++, but I'd be surprised if Darwin > were the only case we need to fix. _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
