Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp4426890rwd; Sun, 4 Jun 2023 05:17:23 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ444vXME1hunpFrbjxzs2Ik4z/hP8x7T5DOfU8Nw0ju925/K/2J94Yzyq/4d2CeNZfseDMg X-Received: by 2002:a05:6a21:33a0:b0:10b:b5cc:6348 with SMTP id yy32-20020a056a2133a000b0010bb5cc6348mr1091962pzb.20.1685881043165; Sun, 04 Jun 2023 05:17:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685881043; cv=none; d=google.com; s=arc-20160816; b=c68e+8sTQvO1evaqQGk6k9AM+knO9LmrgaN5fTpZe4yPhH3JmB+7/ZkzL9GVqz+frd 4v5D4Ce/ThOPySk4yy7RwQP/AjOBtWwFunFk/3jlCKI0taoFK+V4ls7wxlQBQDgpSx4/ SUs9tDGGVTKuvPEqBJdNIN79K8snmNEZVWwTxy+KbsejpJ0JYIVeqWRvm2En5cgvWZsn ojjHaxFHZ9AhA1b6UgJBza3hxEL1MdLtJLCqwxsk3BsgDrqrY/CUprWRl1rc04WPzHQH zPfVInQsXHM9o1+LwNVHA2/WitLWlrtvhuwmtrS3RMg+vI7wbGryLHtbjvtH2s+y1RKH /mSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=7z0nVfB4Iglr3bI12x1C6pIC6LxdnymItMqrl96wTMI=; b=lxhgVJxo5/nUs9ownmH7Pp6d6Lkx4EgvE40vbYiBytlVP2t2+rsTW8eiaaHf1b0sIO SSoCFVFXFxA+Txsi3jfQWt/Fl1K+AJv15j+4omwyXsxJEb0GnY25KWTrEslBC+z4yQJ3 Key8QlZZPq4JQagTe8Ol4b30RSuy6tBFk9JiJQmBRwJ0+MY3G59o1LEAL8ZSF0SQ8Zb1 5vhFxwdzQGmHrJggkQ/9uVDBiru6O8jeiUrKeaCFTTGXfnTYm4YcxJM1Wmgx1w8U4I74 7CDvFVxiuiDpFB/YyYUhMBt8vU7qtWEbTU2owAFFOfWj4DEAbpInCFlC5ePtfpApIy8a +n4A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x2-20020aa79402000000b006581d3c44d1si1018029pfo.89.2023.06.04.05.17.10; Sun, 04 Jun 2023 05:17:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230392AbjFDL7y (ORCPT + 99 others); Sun, 4 Jun 2023 07:59:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40390 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229851AbjFDL7w (ORCPT ); Sun, 4 Jun 2023 07:59:52 -0400 Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 09E0CDB; Sun, 4 Jun 2023 04:59:50 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.17.1/8.17.1/Submit) id 354BxgFu001979; Sun, 4 Jun 2023 13:59:42 +0200 Date: Sun, 4 Jun 2023 13:59:42 +0200 From: Willy Tarreau To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: Shuah Khan , "Paul E. McKenney" , Vincent Dagonneau , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH] tools/nolibc: ensure fast64 integer types have 64 bits Message-ID: References: <20230530-nolibc-fast64-v1-1-883dea6bc666@weissschuh.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jun 04, 2023 at 12:50:03PM +0200, Willy Tarreau wrote: > On Tue, May 30, 2023 at 11:18:00AM +0200, Thomas Wei?schuh wrote: > > On 32bit platforms size_t is not enough to represent [u]int_fast64_t. > > > > Fixes: 3e9fd4e9a1d5 ("tools/nolibc: add integer types and integer limit macros") > > Signed-off-by: Thomas Wei?schuh > > --- > > Cc: Vincent Dagonneau > > > > Note: We could also fall back to compiler-provided data like: > > > > __UINT_FAST{8,16,32,64}_{TYPE,MIN,MAX}__ > > I'm fine with the way you did it. I'm wondering how we managed to miss > this one given the tests in place! BTW, it failed on 32-bit platforms: 4407 tests passed, 84 skipped, 63 failed $ grep '^linux_arch\|FAIL' test14.out linux_arch=i386 qemu_arch=i386 gcc_arch=i386 52 limit_int_fast64_min = -2147483648 [FAIL] 53 limit_int_fast64_max = 2147483647 [FAIL] 54 limit_uint_fast64_max = 4294967295 [FAIL] The reason is that the constants also have to be adjusted. With the fix below everything works right: --- a/tools/include/nolibc/stdint.h +++ b/tools/include/nolibc/stdint.h @@ -84,17 +84,17 @@ typedef uint64_t uintmax_t; #define INT_FAST8_MIN INT8_MIN #define INT_FAST16_MIN INTPTR_MIN #define INT_FAST32_MIN INTPTR_MIN -#define INT_FAST64_MIN INTPTR_MIN +#define INT_FAST64_MIN INT64_MIN #define INT_FAST8_MAX INT8_MAX #define INT_FAST16_MAX INTPTR_MAX #define INT_FAST32_MAX INTPTR_MAX -#define INT_FAST64_MAX INTPTR_MAX +#define INT_FAST64_MAX INT64_MAX #define UINT_FAST8_MAX UINT8_MAX #define UINT_FAST16_MAX SIZE_MAX #define UINT_FAST32_MAX SIZE_MAX -#define UINT_FAST64_MAX SIZE_MAX +#define UINT_FAST64_MAX UINT64_MAX #ifndef INT_MIN #define INT_MIN (-__INT_MAX__ - 1) 4470 tests passed, 84 skipped, 0 failed $ grep '^linux_arch\|fast64' test15.out linux_arch=i386 qemu_arch=i386 gcc_arch=i386 52 limit_int_fast64_min = -9223372036854775808 [OK] 53 limit_int_fast64_max = 9223372036854775807 [OK] 54 limit_uint_fast64_max = -1 [OK] If you're fine with it, I'll squash it into your patch. Thanks, Willy