From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10000 invoked from network); 31 May 2023 14:47:25 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 31 May 2023 14:47:25 -0000 Received: (qmail 24098 invoked by uid 550); 31 May 2023 14:47:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24056 invoked from network); 31 May 2023 14:47:22 -0000 Date: Wed, 31 May 2023 10:47:10 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20230531144710.GE4163@brightrain.aerifal.cx> References: <1c8e850ed3190af39b9e3f501d79899d438e7292.1685536608.git.Jens.Gustedt@inria.fr> <20230531142743.GB4163@brightrain.aerifal.cx> <20230531164254.7a867552@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230531164254.7a867552@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [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 ) > 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