[cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers

[Richard Smith via cfe-dev]

On Jan 23, 2016 10:09 PM, "Howard Hinnant" <howard.hinnant at gmail.com> wrote:
>
> On Jan 23, 2016, at 3:59 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> >
> >> On Jan 23, 2016 9:47 PM, "Howard Hinnant via cfe-dev" <
cfe-dev at lists.llvm.org> wrote:
> >> >
> >> > It was *never* intended to add the C++ overloads to the global
namespace.
> >> >
> >> > I can now see how that is indeed what is written.  Believe me, it
was the farthest thought from *anyone’s* mind when these words were voted
in.  This is demonstrable by looking at the issue which introduced these
words:
> >> >
> >> > http://cplusplus.github.io/LWG/lwg-defects.html#456
> >> >
> >> > The description includes:
> >> >
> >> > > The C headers are often beyond the direct control of C++
implementors. In some organizations, it's all they can do to get a few
#ifdef __cplusplus tests added. Third-party library vendors can perhaps
wrap the C headers. But neither of these approaches supports the drastic
restructuring required by the C++ Standard. As a result, it is still
widespread practice to ignore this conformance requirement, nearly seven
years after the committee last debated this topic. Instead, what is often
implemented is:
> >> > >
> >> > >       • Including the header <xxx.h> declares a C name in the
global namespace.
> >> > >       • Including the header <cxxx> declares a C name in the
global namespace (effectively by including <xxx.h>), then imports it into
namespace std with an individual using declaration.
> >> >
> >> > This was the issue:  C++ lib vendors *not having control* over the C
headers.  The furthest thing from our mind was adding *more* stuff to the C
headers!
> >> >
> >> > Martin is 100% correct as far as historical intent goes.  The
mis-interpretation of these words by Richard and Eric is evidence that the
standard remains buggy in this area.
> >>
> > Thanks, Howard, it's useful to know how we got here.
> >
> > For what it's worth, though, I think the words we have in the standard
now do say the best thing for users, striking a balance between C
compatibility and bug avoidance (even if they don't match the historical
intent), and would argue against changing them -- especially as we do now
have an implementation that follows them.
> >
>
> This thread started with evidence from the field to the contrary.

We have evidence from the field that the lack of overloads of ::fabs causes
(usually hard to detect precision loss) bugs. This thread concerns a
nonstandard extension that I would imagine is only used by a small minority
of libc++ users, and we can handle it by supporting that extension directly
in libc++. (Doing so would fix a couple of other issues: wrong return type,
no support for __fp16 in std::fabs.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160123/605d4194/attachment.html>