[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 31 May 2023 10:47:10 -0400
From: Rich Felker <dalias@...c.org>
To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: [C23 128 bit 4/4] C23: implement proper support for
int128_t and uint128_t
On Wed, May 31, 2023 at 04:42:54PM +0200, Jₑₙₛ Gustedt wrote:
> Rich,
>
> on Wed, 31 May 2023 10:27:44 -0400 you (Rich Felker <dalias@...c.org>)
> wrote:
>
> > (This was the whole reason _BitInt was added, no?)
>
> No, not at all. These are added to have
>
> - types for any width, not only multiples of 8
> - potentially have types that have thousands of bits (clang seems to
> be keen to do so)
> - types that have different rules for conversions, in particular no promotion.
>
> These are explicitly not allowed to be used for the [u]intXXX_t types.
>
> They only appear in the patches I propose as a means to encode number
> literals of the appropriate width. These are used with casts, such
> that they end up with the correct types.
OK, well the motivations behind _BitInt are really aside from the key
question here, which is whether intN_t wider than intmax_t is
permitted. As I read the spec, it's still not. And even if it were
permitted, I don't see where an int128_t type is mandated. J.5.6 even
gives __int128 as an example of an "other arithmetic type" that's not
an "extended integer type" by virtue of not aligning with the intmax_t
requirements.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
