This is the mail archive of the
mailing list for the newlib project.
Re: Support for long long type for C99 and C++11 compliant compilers
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: newlib at sourceware dot org
- Date: Thu, 9 Oct 2014 14:06:26 -0400 (EDT)
- Subject: Re: Support for long long type for C99 and C++11 compliant compilers
- Authentication-results: sourceware.org; auth=none
- References: <1410285946 dot 1215 dot 540 dot camel at raymund7> <20141009123411 dot GB15717 at calimero dot vinschen dot de> <1412864439 dot 1215 dot 4135 dot camel at raymund7> <20141009165305 dot GB25389 at calimero dot vinschen dot de>
----- Original Message -----
> From: "Corinna Vinschen" <firstname.lastname@example.org>
> To: email@example.com
> Sent: Thursday, October 9, 2014 12:53:05 PM
> Subject: Re: Support for long long type for C99 and C++11 compliant compilers
> On Oct 9 16:20, Thomas Uhle wrote:
> > On Thu, 2014-10-09 at 14:34 +0200, Corinna Vinschen wrote:
> > > Hi Thomas,
> > >
> > > On Sep 9 20:05, Thomas Uhle wrote:
> > > > Hello,
> > > >
> > > > the attached patch fixes some issues with long long type support for
> > > > compilers that have C99 or C++11 compliance. For instance, llabs(),
> > > > lldiv() and atoll() have been missing if g++ was invoked with option
> > > > '-std=c++11'.
> > >
> > > Your patch is missing a ChangeLog entry. Also, why do you replace "long
> > > long" with _LONG_LONG_TYPE? Isn't _LONG_LONG_TYPE always "long long"?
> > > Also, while you're doing this in math.h, you're sticking to "long long"
> > > for other declarations like for atoll.
> > >
> > > What's the reasoning here?
> > Hi Corinna,
> > thanks for your reply! The macro _LONG_LONG_TYPE has been used rather
> > inconsistently through math.h, for llroundl() it is _LONG_LONG_TYPE, for
> > llroundf() it is "long long" for instance. I just tried to get its usage
> > aligned for all of these functions. As far as I can see, _LONG_LONG_TYPE
> > is only used in math.h, nowhere else. That is why I did not touch
> > anything else. And _LONG_LONG_TYPE is defined in _ansi.h to be "long
> > long" if _HAVE_STDC is defined and to be just "long" if _HAVE_STDC is
> > not defined. I do not know the rationale, but it seems that it has been
> > there since the time of the following entry in the ChangeLog:
> > | 2007-12-19 Dave Korn <firstname.lastname@example.org>
> > | Jeff Johnston <email@example.com>
> > |
> > | * libc/include/_ansi.h: Add _LONG_LONG definition.
> > | * libc/include/math.h (llrint, llrintf, rintl, lrintl, llrintl):
> > | Add
> > | prototypes.
> > I could perfectly live without _LONG_LONG_TYPE, though. But I do not
> > know whether replacing _LONG_LONG_TYPE by "long long" does break things
> > on any other platform. That is why ...
> That makes sense. I'm not sure either, why _LONG_LONG_TYPE is used in
> math.h and then only for the aforementioned set of functions (and even
> then inconsistently, as you observed).
> Jeff, I see the addition of using _LONG_LONG_TYPE is from you. I don't
> quite grok why this is done for the functions added by Dave Korn, but
> not for other long long functions added later on. It looks like an
> oversight, or the importance of !_HAVE_STDC got negligible.
> AFAICS, using _LONG_LONG_TYPE instead of "long long" for other functions
> now might break the ABI dependend on _HAVE_STDC. I'm not sure there's
> still any compiler out there not having long long, so *if* we go in any
> ABI-breaking direction, I'd prefer to get rid of _LONG_LONG_TYPE and
> define the affected functions always as "long long".
Sure. I'm fine with that.
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat