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

[Richard Smith via cfe-commits]

On Thu, Dec 10, 2015 at 5:24 PM, Duncan P. N. Exon Smith via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> > 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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151211/00585964/attachment.html>