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

Martin J. O'Riordan via cfe-dev cfe-dev at lists.llvm.org
Tue Jan 26 12:09:11 PST 2016


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.

 

            MartinO

 

From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Craig, Ben via cfe-dev
Sent: 26 January 2016 19:42
To: cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> 
Subject: Re: [cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers

 

With regards to "where do we want to be", we shouldn't take the complete opposite approach and have the libcxx provide none of the C headers.  At a minimum, we need a libcxx version of tgmath.h that hides the C version of tgmath.h.  The generic macros from tgmath.h would play havoc with the overloaded functions in cmath.

Maybe all the other libcxx C headers could forward to the underlying C headers (or maybe not), but tgmath.h (and maybe others I'm forgetting) are special, and should not forward to the underlying C header.

On 1/25/2016 4:30 PM, Marshall Clow via cfe-dev wrote:

On Sat, Jan 23, 2016 at 12:46 PM, Howard Hinnant <howard.hinnant at gmail.com <mailto:howard.hinnant at gmail.com> > wrote:

[snip]
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.

 

While I bow to Howard's experience and to his recollection, I have to disagree with his characterization of Richard and Eric's posts as "mis-interpretation".

 

I believe that they have accurately reflected what is written in the standard.

 

But that's just a nit.

The real questions are - where do we want to be, and how can we get there?

 

(and let's not forget http://cplusplus.github.io/LWG/lwg-defects.html#2086) as well, which implies that there is no support for user-defined types in <cmath>.

 

-- Marhsall

 

 





_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> 
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160126/908840f8/attachment.html>


More information about the cfe-dev mailing list