From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by sourceware.org (Postfix) with ESMTPS id 9458F3858D28 for ; Tue, 23 Nov 2021 14:18:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9458F3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=arndb.de Received: from mail-wm1-f45.google.com ([209.85.128.45]) by mrelayeu.kundenserver.de (mreue106 [213.165.67.113]) with ESMTPSA (Nemesis) id 1M5xDJ-1mjjCt1Udv-007TAb for ; Tue, 23 Nov 2021 15:18:56 +0100 Received: by mail-wm1-f45.google.com with SMTP id o29so18884677wms.2 for ; Tue, 23 Nov 2021 06:18:56 -0800 (PST) X-Gm-Message-State: AOAM530y3ZAn0uaBy+6KjK0FTqejMBAORg3/j0umYdY4RqvON4Vs6CV1 C+kszKw+xKKSxECSf6u0vlEq4RuqUycl5v5jCn0= X-Google-Smtp-Source: ABdhPJy/iu+HUeUW5MAS4aoS4UPs9O0+2rPHcGIO3sxNnrXnPW2hntwc4AmghGSopXx9bjgxeEGyK0ovTBLVT2Rzyac= X-Received: by 2002:a1c:770e:: with SMTP id t14mr3353750wmi.173.1637677135896; Tue, 23 Nov 2021 06:18:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Tue, 23 Nov 2021 15:18:39 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace To: Cyril Hrubis Cc: Arnd Bergmann , Linux Kernel Mailing List , Linux API , LTP List , GNU C Library , linux-arch Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:+Eb9Esmj9H82QlpmTDGjFiXLZ4O8vW8Q2JQYaT+PVvmqJWML8nm 9g3plxANF3Ltw6hLF7YfjOftBpdgOT6630Jn0rfWphGHxo8P6w74WwuohKvCykeX9fZO5wh mbc3OTuHBP2ZW3FeTCMB8qWOg21toxLsbVymoQ3KZU8DBh4Q6ijvt2H06WVnKqrp1wxrps8 5Jw6FVYbplvlT7Nckd+0Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:3ILWF1K54IU=:Kp0pDz/r6fE67HQVwp94ML nsLpNHi5aRcSNGjo1E3nMDYbZ5oCYyDo69BmWi1X1QxQiRLGIB+BbUheHuYCcndc8b0jpY/cU tqYYnti9j/e620XgjrEfSttj5nxSd0oyQjK19dJyN5O7LjAWJ7tYGOUAF4GkGf3g5U1BbAGCb n5TxkitDDXNE+UaV2NMjkjbd6sr9ZLbcu59HjETlB9VvyQDPuWyi4cNHDz2163dTnEaiAwNXL Q1G4p48+JDe2zqVXkR8LbeVFuaoMULIxXEUUHTGRfWYmNKBT4t74QiZxf98hPD9m/PKQwpWOl RMEfeUELXhZ0ap268nbp8lmCXTZPSvw/y2+7GQF1HPnISRRCUFUjHte/kW7QWC2aTjsDYqZ1l o5+pv1YPgKlJUfpEDJwxQlchFbAZIE5XfU3EDeiiTYRZN9WhVGUOzD6UBzlhNiLJWrDbmCYns UkacgwcjylxjmKaKwAUwAb2jujbaxRakbn03+yc+ZzvvFQ0KABYOyVK/8hlG1NmgQvzlqPVi9 F6VxaRuhKdHeZOwnIjTJdvwFxDwnAHcU2t1LpEQFSe8Yz75kupk7OmY5H6s47xGAdCk1rpfjA FxLF+cT6s3G6DGfheLOjAiOCQNG8STz91hRBYxgi9iTLfau1F1DnDHLEpavRT+sLUeJsTyZB2 +bN69cWVXKSQMxfIT5FRuCjqIWJYJ5lKrOX4OhAwMzRB811FcA5kdn+0qvIKBlNd0mB3PLMY9 wrZfJVmxEo9dWdf296xmq1rJQr0jTgZq9XVA92NkSf2icqUBFEgHHjS2HCTV5mt71N8uv1erH n2ad1fhB0mm2BLvZ7z1i2r83LKch4rO3hwHzxrwY4cuFhBtzbI= X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 14:18:59 -0000 On Tue, Nov 23, 2021 at 10:14 AM Cyril Hrubis wrote: > > I don't think this is correct on all 64-bit architectures, as far as I > > remember the > > definition can use either 'long' or 'long long' depending on the user space > > toolchain. > > As far as I can tell the userspace bits/types.h does exactly the same > check in order to define uint64_t and int64_t, i.e.: > > #if __WORDSIZE == 64 > typedef signed long int __int64_t; > typedef unsigned long int __uint64_t; > #else > __extension__ typedef signed long long int __int64_t; > __extension__ typedef unsigned long long int __uint64_t; > #endif > > The macro __WORDSIZE is defined per architecture, and it looks like the > defintions in glibc sources in bits/wordsize.h match the uapi > asm/bitsperlong.h. But I may have missed something, the code in glibc is > not exactly easy to read. It's possible that the only difference between the two files was the '__u32'/'__s32' definition, which could be either 'int' or 'long'. We used to try matching the user space types for these, but not use 'int' everywhere in the kernel. > > Out of the ten supported 64-bit architectures, there are four that already > > use asm-generic/int-l64.h conditionally, and six that don't, and I > > think at least > > some of those are intentional. > > > > I think it would be safer to do this one architecture at a time to make > > sure this doesn't regress on those that require the int-ll64.h version. > > I'm still trying to understand what exactly can go wrong here. As long > as __BITS_PER_LONG is correctly defined the __u64 and __s64 will be > correctly sized as well. The only visible change is that one 'long' is > dropped from the type when it's not needed. Correct, I'm not worried about getting incorrectly-sized types here, but using the wrong type can cause compile-time warnings when they are mismatched against format strings or assigning pointers to the wrong types. With the kernel types, one would always use %d for __u32 and %lld for __u64, while with the user space types, one has to resort to using macros. Arnd