This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: missing methods in inttypes.h
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: <newlib at sourceware dot org>
- Date: Sun, 4 Aug 2013 20:41:22 +0000
- Subject: Re: missing methods in inttypes.h
- References: <51F678CC dot 2070901 at oarcorp dot com> <20130730091311 dot GM4166 at calimero dot vinschen dot de> <51F7C6FC dot 7070101 at oarcorp dot com> <20130730155734 dot GR4166 at calimero dot vinschen dot de> <51FAA2F0 dot 4010606 at oarcorp dot com> <51FABA86 dot 2030405 at redhat dot com> <20130802075120 dot GB19078 at calimero dot vinschen dot de> <51FBC1BC dot 7090308 at LGSInnovations dot com> <51FBE51A dot 5070402 at redhat dot com> <20130802174108 dot GI4166 at calimero dot vinschen dot de>
On Fri, 2 Aug 2013, Corinna Vinschen wrote:
> That reminds me of a type weirdness. On x86_64, gcc supports the
> datatype __int128. Nevertheless, when asking for the size of intmax_t,
> it returns 8, not 16. This is independent of the platform. The result
> of the following testcase is the same on Linux as well as on Cygwin:
I think of __int128 as a "sui generis extended type", and not an "extended
integer type". Although in principle it would be perfectly possible to
change intmax_t in the glibc ABI so as to make __int128 an extended
integer type (using symbol versioning as was done for long double for
various architectures some years ago), it's not clear it's sufficiently
useful to do so.
--
Joseph S. Myers
joseph@codesourcery.com