This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: missing methods in inttypes.h
- From: Corinna Vinschen <vinschen at redhat dot com>
- To: newlib at sourceware dot org
- Date: Fri, 2 Aug 2013 20:18:57 +0200
- Subject: Re: missing methods in inttypes.h
- References: <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> <51FBF344 dot 8060208 at redhat dot com>
- Reply-to: newlib at sourceware dot org
On Aug 2 11:58, Eric Blake wrote:
> On 08/02/2013 11:41 AM, Corinna Vinschen wrote:
> > On Aug 2 10:58, Eric Blake wrote:
> >> On 08/02/2013 08:27 AM, Craig Howland wrote:
> >>>
> >>> On 08/02/2013 03:51 AM, Corinna Vinschen wrote:
> >>>> That, and the alias implementation would fix all your concerns, as
> >>>> long as the types (long long vs. intmax_t) have the same size. Do we
> >>>> have targets without long long? Do we have targets with intmax_t >
> >>>> long long? I hope not... Corinna
> >>> We do not have any targets with intmax_t > long long, as the standards
> >>> require intmax_t >= long long.
> >>
> >> That's a non sequitur. It is feasible (although currently unlikely) to
> >> have a platform with 64-bit 'long long' but 128-bit 'int128_t'; on such
> >> a platform, intmax_t would have to be int128_t.
> >
> > 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.
>
> That's because intmax_t is still set to the largest non-internal type,
> int64_t. If someone adds 'typedef __int128 int128_t' to expose a
> 128-bit integer out of the realm of reserved for the implementation and
> into the realm of usable by standards-conforming programs, then that
> same person better also adjust intmax_t to match.
>
> >
> > That behaviour seems to be not standards conformant...
>
> You left standards conformance behind when you used a double-underscore
> keyword.
Ooh, the fine points... ;)
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat