[libcxx] Reinstate <string.h> and fix overload sets to be const-correct wherever possible

[Duncan P. N. Exon Smith via cfe-commits]

> On 2015-Dec-10, at 15:32, Richard Smith <richard at metafoo.co.uk> wrote:
> 
> On Thu, Dec 10, 2015 at 11:45 AM, Marshall Clow <mclow.lists at gmail.com> wrote:
> On Tue, Dec 8, 2015 at 3:52 PM, Richard Smith <richard at 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.