[cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers
Richard Smith via cfe-dev
cfe-dev at lists.llvm.org
Tue Feb 2 12:22:09 PST 2016
Also, see http://cplusplus.github.io/LWG/lwg-defects.html#2380 where
LWG agreed that libc++'s current behavior is the desired behavior.
On Tue, Feb 2, 2016 at 12:16 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> This is not really the time to be sending patches; we have not yet
> established what the desired direction is. Even if we agreed that this
> was the right direction and that we wanted to regress our conformance
> here, this patch is not acceptable as it breaks modules support. (It
> also breaks the include guard optimization for many of libc++'s
> headers.)
>
> On Tue, Feb 2, 2016 at 2:29 AM, Martin J. O'Riordan via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>> Sorry for the delay getting back to this. I am attaching a revised patch
>> (with respect to #259486) that addresses the issue that James commented on.
>> The test case:
>>
>>
>>
>> test/std/depr/depr.c.headers/math_h.pass.cpp
>>
>>
>>
>> fails with these changes, but this is because the test is expecting the
>> names in ‘<math.h>’ to be overloaded in the global namespace. I also made
>> some additional changes to ‘<stdio.h>’ to wrap the macros for ‘getc’,
>> ‘putc’, etc. using the same pattern that is used to achieve the same task in
>> ‘<math.h>’. The ‘#undef’s for these was causing link failures for against
>> our C library which does not provide callable functions for these and
>> instead uses the macros provided by Newlib. I liked the pattern used in
>> ‘<math.h>’ and thought that it neatly addressed the requirements of C++.
>> Similar changes are probably a good idea for ‘<ctype.h>’ and ‘<wctype.h>’,
>> but I did not implement these.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> MartinO
>>
>>
>>
>> From: Martin J. O'Riordan [mailto:martin.oriordan at movidius.com]
>> Sent: 27 January 2016 15:41
>> To: 'James Y Knight'
>> Cc: 'David Chisnall'; 'Clang Dev'
>> Subject: RE: [cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers
>>
>>
>>
>> Hmm! In order for it to matter, the program would have to do:
>>
>>
>>
>> #include <math.h>
>>
>> #include <cmath>
>>
>>
>>
>> which I think is unlikely, but:
>>
>>
>>
>> #include <math.h>
>>
>> #include “otherfile.h”
>>
>>
>>
>> where ‘otherfile.h’ then includes ‘<cmath>’, which is more likely to happen
>> when ‘<cmath>’ is included by proxy after ‘<math.h>’. But you are correct,
>> I hadn’t thought of this and the pattern would need to be refined to address
>> this. I did not come across this scenario in the LibC++ test-suite or my
>> own.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> MartinO
>>
>>
>>
>> From: James Y Knight [mailto:jyknight at google.com]
>> Sent: 27 January 2016 15:29
>> To: Martin J. O'Riordan
>> Cc: David Chisnall; Clang Dev
>>
>>
>> Subject: Re: [cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers
>>
>>
>>
>> This doesn't seem right -- won't it break code that does this:
>>
>> #include <math.h>
>>
>> #include <cmath>
>>
>> ? (since the "#ifdef _LIBCPP_INCLUDING_STDC_HEADER" is within the "#ifndef
>> _LIBCPP_MATH_H" block, and thus only gets checked once)
>>
>>
>>
>>
>>
>> On Wed, Jan 27, 2016 at 10:22 AM, Martin J. O'Riordan via cfe-dev
>> <cfe-dev at lists.llvm.org> wrote:
>>
>> 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.
>>
>>
>> I have also attached a patch file computed against the #258931 revision on:
>>
>> https://llvm.org/svn/llvm-project/libcxx/branches/release_38/include
>>
>> Although many files have changed, the nature of the changes is quite simple.
>>
>> o In each of the '<cXXXX>' files I have inserted:
>>
>> #define _LIBCPP_INCLUDING_STDC_HEADER
>>
>> before each '#include <####.h>' ISO C header, and followed by:
>>
>> #undef _LIBCPP_INCLUDING_STDC_HEADER
>>
>> I have done this for all LibC++ headers that include an ISO C header
>> even if
>> it does not refer to a LibC++ wrapping header, in case one C header
>> includes another in any particular ISO C header implementation.
>>
>> o In each of the '<XXXX.h>' ISO C header wrappers, where appropriate I
>> have
>> replaced:
>>
>> #ifdef __cplusplus
>> ...
>> #endif // __cplusplus
>>
>> with:
>>
>> #ifdef _LIBCPP_INCLUDING_STDC_HEADER
>> ...
>> #endif // _LIBCPP_INCLUDING_STDC_HEADER
>>
>> o Before the C++ overloaded functions are introduced at global scope, I
>> have
>> inserted:
>>
>> _LIBCPP_BEGIN_NAMESPACE_STD
>>
>> and afterwards:
>>
>> _LIBCPP_END_NAMESPACE_STD
>>
>> o Finally, in '<math.h>' in particular, I have prefixed the forwarded
>> names with '::' since at this point in the 'using ::name;' has not yet
>> been seen.
>>
>> 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.
>>
>> MartinO
>>
>> -----Original Message-----
>> From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David
>> Chisnall
>> Sent: 27 January 2016 9:25
>> To: Martin.ORiordan at Movidius.com
>> Cc: Craig, Ben; Clang Dev
>> Subject: Re: [cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers
>>
>> On 26 Jan 2016, at 20:09, Martin J. O'Riordan via cfe-dev
>> <cfe-dev at lists.llvm.org> wrote:
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>
>> 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…
>>
>> 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.
>>
>> David
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
More information about the cfe-dev
mailing list