From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 86EEB1F953 for ; Tue, 23 Nov 2021 16:58:56 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1CC163858D28 for ; Tue, 23 Nov 2021 16:58:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1CC163858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1637686735; bh=loBrNqiFElVzJ3IERgqNbQpIHtDNCaCMAIW/dLMlS6w=; h=To:Subject:Date:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Ddm1Ex/UA98weoGE30lBCLnKoPDS3aMpaxMu/xRew33K4pdgyiBCBjTPtvl0oVMcy bTgUeoe4UZyhNURh1wYi0TWg927S6JfahRLqM5gvAZdcM8HgcyY10K3Kh0FhHkoBBm IFy/lOBsZFgDgNyaBShhONmkKxS6fwDMFXzTLyv4= Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [207.82.80.151]) by sourceware.org (Postfix) with ESMTPS id 0266A3858D28 for ; Tue, 23 Nov 2021 16:58:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0266A3858D28 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mtapsc-8-dyIDGajdPWOdiVq8f9AjNQ-1; Tue, 23 Nov 2021 16:58:31 +0000 X-MC-Unique: dyIDGajdPWOdiVq8f9AjNQ-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Tue, 23 Nov 2021 16:58:31 +0000 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.026; Tue, 23 Nov 2021 16:58:30 +0000 To: 'David Howells' , Cyril Hrubis Subject: RE: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace Thread-Topic: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace Thread-Index: AQHX4InVzhztkrNZME2rQ+mb6OtfjawRUyrg Date: Tue, 23 Nov 2021 16:58:30 +0000 Message-ID: References: <1618289.1637686052@warthog.procyon.org.uk> In-Reply-To: <1618289.1637686052@warthog.procyon.org.uk> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: , From: David Laight via Libc-alpha Reply-To: David Laight Cc: "linux-arch@vger.kernel.org" , "libc-alpha@sourceware.org" , "linux-api@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "ltp@lists.linux.it" Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" From: David Howells > Sent: 23 November 2021 16:48 >=20 > Cyril Hrubis wrote: >=20 > > This changes the __u64 and __s64 in userspace on 64bit platforms from > > long long (unsigned) int to just long (unsigned) int in order to match > > the uint64_t and int64_t size in userspace. That is a massive UAPI change you can't do. > Can you guarantee this won't break anything in userspace? Granted the ty= pes > *ought* to be the same size, but anyone who's written code on the basis t= hat > these are "(unsigned) long long int" may suddenly get a bunch of warnings > where they didn't before from the C compiler. Anyone using C++, say, may= find > their code no longer compiles because overloaded function matching no lon= ger > finds a correct match. Indeed > Also, whilst your point about PRIu64 and PRId64 modifiers in printf() is = a > good one, it doesn't help someone whose compiler doesn't support that (I = don't > know if anyone's likely to encounter such these days). At the moment, I = think > a user can assume that %llu will work correctly both on 32-bit and 64-bit= on > all arches, but you're definitely breaking that assumption. PRIu64 (etc) don't require compiler support, just the correct header file. I'm pretty sure that portable user code needs to allow for int64_t being either 'long' or 'long long' on 64bit architectures. (Indeed 'long' may not even be 64bit.) On 32bit int32_t can definitely be either 'int' of 'long' at whim. I'm not sure anyone has tried a 64bit long with a 128bit long-long. But the C language might lead you to do that. Of course, fully portable code has to allow for char, short, int and long all being the same size! =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)