From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id 489F1385841B for ; Wed, 8 Dec 2021 03:06:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 489F1385841B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=libc.org Date: Tue, 7 Dec 2021 22:05:59 -0500 From: Rich Felker To: Zack Weinberg Cc: "'Alejandro Colomar (man-pages)'" , libc-alpha@sourceware.org, =?utf-8?B?0L3QsNCx?= , Jakub Wilk , Stefan Puiu , Michael Kerrisk , "H . J . Lu" , Joseph Myers Subject: Re: [RFC v2 1/2] sys/types.h: Define new type: snseconds_t Message-ID: <20211208030558.GS7074@brightrain.aerifal.cx> References: <20211207111957.8087-1-alx.manpages@gmail.com> <20211207214814.18553-1-alx.manpages@gmail.com> <20211208002911.GR7074@brightrain.aerifal.cx> <90c79268-f5a1-4990-84a5-fd0a508046d2@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90c79268-f5a1-4990-84a5-fd0a508046d2@www.fastmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, 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: Wed, 08 Dec 2021 03:06:06 -0000 On Tue, Dec 07, 2021 at 09:26:59PM -0500, Zack Weinberg wrote: > On Tue, Dec 7, 2021, at 7:29 PM, Rich Felker wrote: > > On Tue, Dec 07, 2021 at 10:48:14PM +0100, Alejandro Colomar wrote: > >> Based on the existing suseconds_t type. > >> > >> The timespec(3) structure uses long for tv_nsec, > >> except if __x86_64__ && __ILP32__, > >> in which case it uses long long. > >> Let's define a stable type that can be relied upon by users, > >> for example for creating pointers. > > > > This is a non-starter because the relevant standards already require > > the tv_nsec member to have type long. > > That requirement is a defect in the standards, and I see no reason > why this particular defect should be granted 'we're stuck with this' > status. When the standard codifies existing *universal* practice without introducing a gratuitous typedef, then the Linux kernel folks fail to read it and make a weird new ABI that breaks it and the glibc folks copy that non-critically (rather than doing the obvious padding thing), it's not a defect in the standard. It's a defect in the review process on the Linux and glibc side. > > x32 just needs to be fixed to match the requirement. > > This doesn't just affect x32, it affects every ABI with 32-bit long > and 64-bit time_t. Look at the ifdef mess in glibc > bits/types/struct_timespec.h if you don't believe me. They all got it right -- tv_nsec has type long (32-bit). There is nothing affected by the issue described here except x32, and it's easily fixed. We've always had it right on musl x32 too. Rich