<div dir="ltr">This doesn't seem right -- won't it break code that does this:<blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>#include <math.h></div></div><div><div>#include <cmath></div></div></blockquote><div>? (since the "<span style="font-size:12.8px">#ifdef _LIBCPP_INCLUDING_STDC_HEADER"</span> is within the "#ifndef _LIBCPP_MATH_H" block, and thus only gets checked once)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 10:22 AM, Martin J. O'Riordan via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I suppose I am more focussed on embedded systems than hosted - thus the reference to 'newlib'; and I'm sure that there are many alternative STDC libraries that I have never heard of. But I think that the LibC++ wrapper headers is still a good place to abstract such portability issues so that users of LibC++ are unaware of the ISO C header implementation that lies beneath.<br>
<br>
<br>
I have also attached a patch file computed against the #258931 revision on:<br>
<br>
<a href="https://llvm.org/svn/llvm-project/libcxx/branches/release_38/include" rel="noreferrer" target="_blank">https://llvm.org/svn/llvm-project/libcxx/branches/release_38/include</a><br>
<br>
Although many files have changed, the nature of the changes is quite simple.<br>
<br>
o In each of the '<cXXXX>' files I have inserted:<br>
<br>
#define _LIBCPP_INCLUDING_STDC_HEADER<br>
<br>
before each '#include <####.h>' ISO C header, and followed by:<br>
<br>
#undef _LIBCPP_INCLUDING_STDC_HEADER<br>
<br>
I have done this for all LibC++ headers that include an ISO C header even if<br>
it does not refer to a LibC++ wrapping header, in case one C header<br>
includes another in any particular ISO C header implementation.<br>
<br>
o In each of the '<XXXX.h>' ISO C header wrappers, where appropriate I have<br>
replaced:<br>
<br>
#ifdef __cplusplus<br>
...<br>
#endif // __cplusplus<br>
<br>
with:<br>
<br>
#ifdef _LIBCPP_INCLUDING_STDC_HEADER<br>
...<br>
#endif // _LIBCPP_INCLUDING_STDC_HEADER<br>
<br>
o Before the C++ overloaded functions are introduced at global scope, I have<br>
inserted:<br>
<br>
_LIBCPP_BEGIN_NAMESPACE_STD<br>
<br>
and afterwards:<br>
<br>
_LIBCPP_END_NAMESPACE_STD<br>
<br>
o Finally, in '<math.h>' in particular, I have prefixed the forwarded<br>
names with '::' since at this point in the 'using ::name;' has not yet<br>
been seen.<br>
<br>
The patch is a suggestion, and the '_LIBCPP_INCLUDING_STDC_HEADER' name I picked are just my idea for following the existing convention used by the LibC++ maintainers.<br>
<span class="im HOEnZb"><br>
MartinO<br>
<br>
-----Original Message-----<br>
From: Dr D. Chisnall [mailto:<a href="mailto:dc552@hermes.cam.ac.uk">dc552@hermes.cam.ac.uk</a>] On Behalf Of David Chisnall<br>
</span><span class="im HOEnZb">Sent: 27 January 2016 9:25<br>
To: Martin.ORiordan@Movidius.com<br>
Cc: Craig, Ben; Clang Dev<br>
Subject: Re: [cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers<br>
<br>
</span><div class="HOEnZb"><div class="h5">On 26 Jan 2016, at 20:09, Martin J. O'Riordan via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> And C++ also requires that some parts of the interfaces from C are presented to C++ as functions - examples being ‘fpclassify’, ‘signbit’ etc. These have to be handled differently, and I think that the current LibC++ approach to these is good and maintains semantic compatibility with C.<br>
><br>
> I had intended to build a patch file of my changes today in case anyone is interested, but other things got me busy. I’ll do that tomorrow and attach it to this thread.<br>
><br>
> I think that it is a good idea to have LibC++ provide its own wrapper headers for the C headers. It is a logical place to deal with portability issues that arise when referring to C headers provided by newlib, uclibc or glibc (and other less well known implementations). The handling of these portability issues will mean that the ‘c’ prefixed C++ headers will need little or no alteration and just maintain the ‘std’ namespace.<br>
><br>
<br>
I note that none of your listed libc implementations are the defaults on the operating systems that ship libc++ as the default C++ standard library implementation…<br>
<br>
It would be very helpful for people who are working on this to provide a set of recommendations for C library maintainers to make C++ interoperability easier. That way, those of us who do have control over the libc headers can work from the other end to improve the situation.<br>
<br>
David<br>
</div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>