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

[Howard Hinnant via cfe-dev]

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.

Howard