From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by sourceware.org (Postfix) with ESMTPS id 2384C3858D3C for ; Wed, 8 Dec 2021 15:59:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2384C3858D3C Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id BA339320112B; Wed, 8 Dec 2021 10:59:26 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute5.internal (MEProxy); Wed, 08 Dec 2021 10:59:27 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjeekgdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfkggrtghk ucghvghinhgsvghrghdfuceoiigrtghksehofihlfhholhhiohdrohhrgheqnecuggftrf grthhtvghrnhephfeuhfevueffteffgfejtefgkeekheeftdeflefgheffffevheekleef gfehffdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4930F24A0074; Wed, 8 Dec 2021 10:59:25 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4492-g121c2470aa-fm-20211206.001-g121c2470 Mime-Version: 1.0 Message-Id: <64379558-2b59-40df-94ac-e5de10cdfe70@www.fastmail.com> In-Reply-To: References: <20211207111957.8087-1-alx.manpages@gmail.com> <20211208144757.37641-2-alx.manpages@gmail.com> Date: Wed, 08 Dec 2021 10:59:04 -0500 From: "Zack Weinberg" To: "Joseph Myers" Cc: "'Alejandro Colomar (man-pages)'" , "Rich Felker" , "Stefan Puiu" , "Andreas Schwab" , "Michael Kerrisk" , =?UTF-8?Q?=D0=BD=D0=B0=D0=B1?= , "Jakub Wilk" , libc-alpha@sourceware.org Subject: Re: [RFC v3 2/3] sys/types.h: struct timespec: Use __snseconds_t for tv_nsec Content-Type: text/plain X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham 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 15:59:31 -0000 On Wed, Dec 8, 2021, at 10:24 AM, Joseph Myers wrote: > On Wed, 8 Dec 2021, Zack Weinberg wrote: >> All my grousing about spec bugs aside, the _point_ of having tv_nsec's >> type be a typedef is that it ought to be possible to make this >> preprocessor conditional (and the rest of the cases in the same if-else >> chain) less hairy. Can you look into that please? > > The question about whether there is padding around tv_nsec is a separate > one to what the type of tv_nsec is. I don't see how you can avoid the > conditionals related to padding, which is what these conditionals are > about. And the preprocessor doesn't readily lend itself to saying "if > tv_sec is 64-bit and tv_nsec is 32-bit" to describe when padding is > involved. I'm hoping we can get to something like this struct timespec { __time_t tv_sec; #if __TIMESPEC_PAD_BEFORE_TV_NSEC int : __TIMESPEC_PAD_BEFORE_TV_NSEC; #endif __snseconds_t tv_nsec; }; where __TIMESPEC_PAD_BEFORE_TV_NSEC is defined in some appropriate sysdeps header (bits/wordsize.h is the first thing to come to mind but I'm not sure it's optimal). Maybe we'd also need __TIMESPEC_PAD_AFTER_TV_NSEC, if the alignment requirement of __time_t is insufficient to make the compiler insert tail padding on some architectures. zw