From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [IPv6:2001:19f0:5:42::1]) by sourceware.org (Postfix) with ESMTPS id BFF77385803F for ; Mon, 15 Jan 2024 22:26:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BFF77385803F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=libc.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BFF77385803F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:19f0:5:42::1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705357597; cv=none; b=C5tqynYQ1EsxsRn6Udo4KrcV7y2WDbWf+3jO/+FSbhekLhs0Cbpn7OL8Oc/GEcHoSW4MwuIyVuMeqhp6FTrX7nvSPb5KCppeU5hRCNWo4CgX7c1DmAdWd4mX2coX82CujCJCwUoBa5xV/zfqLPwTHcsPGKg6pg5D7R1ZCmUSkU0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705357597; c=relaxed/simple; bh=O4vfckVm9j9sFbbfGda4AaPRILM29YF1HQ/pdVK7WoA=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=cOT32vhiHdWf5O+sQhPH5NvF06OKATIgEsnMZuXAj3nONJaNx5j+VzghriC6LfJkH2byxuQtu4qMQvRZLaIC8U43+PQsIHojSpvkLLHKhE4WWQJufR+pG6ykbtXSitifEA7TeC7Dbf/5iGH7SAiq/51WmMbAyJVMzDKJVCFvXH0= ARC-Authentication-Results: i=1; server2.sourceware.org Date: Mon, 15 Jan 2024 17:26:48 -0500 From: Rich Felker To: Adhemerval Zanella Netto Cc: Florian Weimer , Antonios Salios via Libc-help , Antonios Salios , Jan Henrik Weinstock , Lukas =?utf-8?Q?J=C3=BCnger?= Subject: Re: 64 bit time_t on riscv32 Message-ID: <20240115222648.GO22081@brightrain.aerifal.cx> References: <877cka7m09.fsf@oldenburg.str.redhat.com> <111c4bfb-bc58-412e-9a37-a5c2ed7f0e3c@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <111c4bfb-bc58-412e-9a37-a5c2ed7f0e3c@linaro.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_NONE,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 Mon, Jan 15, 2024 at 04:55:30PM -0300, Adhemerval Zanella Netto wrote: > > > On 15/01/24 10:40, Florian Weimer via Libc-help wrote: > > * Antonios Salios via Libc-help: > > > >> According to a kernel maintainer, the __USE_TIME_BITS64 macro should be > >> set on architectures that use 64-bit time [2], otherwise the kernel > >> headers will not be able to pick the correct definition. > > > > __USE_TIME_BITS64 is an internal glibc macro. It is not used on > > architectures which have a 64-bit time_t by default. > > > > Surely the UAPI headers know which time size the architecture uses in > > the kernel interface, and can be written arcordingly? > > The use of a glibc internal definition on a kABI header is not really > a good design. This seems to be only user so far, so I suggest to fix > on the kernel to not tie to a glibc internal definition. > > CCing Rich from musl that most likely would want to see this fixed. The > Android developers might be interested. At the time this was done, I understood __USE_TIME_BITS64 as the contract between the userspace implementation and the kernel uapi headers to say "we use 64-bit time_t and want the 64-bit version of the types/ioctls/etc." That's what musl does -- we always define __USE_TIME_BITS64, unconditionally. I haven't read this whole thread, but it sounds like glibc's rv32 port is breaking their own contract and not defining __USE_TIME_BITS64... Rich