From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 298FD3851C25 for ; Thu, 25 Aug 2022 07:28:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 298FD3851C25 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1661412519; bh=9K2f0e10ZANjjOudPs4B7euHG9H2+iiRuaYv5ZJbA1k=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=nmfnx0FO7b7ckLx4wu28ch41hPeeFb8cw/Rec9LmSdOzvBzyZRKWr29E2ij+mZidq p+PyBUS94RPQ8ZVOQohv/ssSTzNWvFVIBOAK2oXYYvF8PxE+ncWh8Qc0BRBwiC+nYu 1x1J2Ybes6HSKUHLHDFj3IlLEWTGqKVW0tWQGC4U= Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 1A8FD6684B; Thu, 25 Aug 2022 03:28:33 -0400 (EDT) Message-ID: <5a3ce36a284fe988694d2e75117aca5f9af66194.camel@xry111.site> Subject: Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming From: Xi Ruoyao To: Alejandro Colomar , Linus Torvalds Cc: linux-man , Rich Felker , Alexei Starovoitov , David Howells , Alexei Starovoitov , Joseph Myers , linux-arch , Zack Weinberg , Daniel Borkmann , Alex Colomar , Michael Kerrisk , Cyril Hrubis , Arnd Bergmann , GCC , LTP List , Florian Weimer , glibc , Greg Kroah-Hartman , LKML , David Laight , Linux API , bpf Date: Thu, 25 Aug 2022 15:28:32 +0800 In-Reply-To: <20d93962-538c-d2c9-1696-a1bdbffa87f8@gmail.com> References: <20210423230609.13519-1-alx.manpages@gmail.com> <20220824185505.56382-1-alx.manpages@gmail.com> <20d93962-538c-d2c9-1696-a1bdbffa87f8@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.45.2 MIME-Version: 1.0 X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROM_SUSPICIOUS_NTLD,LIKELY_SPAM_FROM,PDS_OTHER_BAD_TLD,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 2022-08-25 at 09:20 +0200, Alejandro Colomar via Gcc-patches wrote: > I don't know for sure, and I never pretended to say otherwise.=C2=A0 But = what=20 > IMHO the kernel could do is to make the types compatible, by typedefing= =20 > to the same fundamental types (i.e., long or long long) that user-space= =20 > types do. In user-space things are already inconsistent as we have multiple libc implementations. Telling every libc implementation to sync their typedef w/o a WG14 decision will only cause "aggressive discussion" (far more aggressive than this thread, I'd say). If int64_t etc. were defined as builtin types since epoch, things would be a lot easier. But we can't change history. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University