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 334B6385843B for ; Tue, 16 Jan 2024 20:42:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 334B6385843B 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 334B6385843B 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=1705437776; cv=none; b=RKPllrieSHiVUkNvsL9nrySuU+xHZGf/YUMlmZFv6Pv7KWPv5dgH7H728SU7HZ25rOP7YTrpRhCVuusvyRSukYLdS3HUAdMQg32keEA7d03XlsN2qeim8xw2Zo39jP60X/aVAmLvMimLa6+KatKnBgLaUOwKAFfxbcz3j4oKTag= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705437776; c=relaxed/simple; bh=HDSBwBQn8FaRsi1tlwDfB4G1tcfHmlEMEMIsNpVx74Y=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=cA01/ZrwS58xg1mi8iLrZoKVStsmfWNLFy8noSXmdu5+o5AHZ1FEW2UklYgMiYB9MtWU0KK7UXRBE3oFvdoZVCufTjvEgUlY5P+eb0lMBoLhoISldZBCn8W8HHECsDUGkUYnKKZmsn/5RZYxthILkF7qZdrPE8ngptQyXUt7XuQ= ARC-Authentication-Results: i=1; server2.sourceware.org Date: Tue, 16 Jan 2024 15:43:09 -0500 From: Rich Felker To: Florian Weimer Cc: Adhemerval Zanella Netto , 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: <20240116204309.GR22081@brightrain.aerifal.cx> References: <877cka7m09.fsf@oldenburg.str.redhat.com> <111c4bfb-bc58-412e-9a37-a5c2ed7f0e3c@linaro.org> <20240115222648.GO22081@brightrain.aerifal.cx> <8734ux2sdy.fsf@oldenburg.str.redhat.com> <20240116155650.GQ22081@brightrain.aerifal.cx> <87r0ih1c4g.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87r0ih1c4g.fsf@oldenburg.str.redhat.com> 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 Tue, Jan 16, 2024 at 05:22:55PM +0100, Florian Weimer wrote: > * Rich Felker: > > > On Tue, Jan 16, 2024 at 04:46:17PM +0100, Florian Weimer wrote: > >> * Adhemerval Zanella Netto: > >> > >> > My understanding was __USE_TIME_BITS64 would be required only for ABIs > >> > that actually would multiple time_t sizes and the glibc 64 bit time_t > >> > supported was added on this assumption. However, the design document > >> > does state __USE_TIME_BITS64 would be defined even for architectures > >> > where is does not require it. I it was not really caught in development > >> > because the design creator was not really much involved at the time. > >> > > >> > I think it should be feasible to fix it, although backporting it would > >> > generate a quite large patch. > >> > >> It will break applications that use __USE_TIME_BITS64 with glibc's > >> current semantics centered on time64 redirects (incorrectly, of > >> course—it's an internal macro). I think the use in the kernel is > >> probably easier to address, and it has to be changed for compatibility > >> with other libcs anyway. > > > > If there are applications assuming __USE_TIME_BITS64 implies redirects > > and doing some hack around that, they really need to be fixed not to > > do that. It will break on musl with (not yet merged) rv32 port as well > > as any future 32-bit ports, which won't have any redirects because > > there is no legacy 32-bit time_t ABI to support. > > That's actually not a problem because __USE_TIME_BITS64 is not defined > on rv32 et al. (hence the complaint about what the UAPI headers are > doing). It is a problem for musl users because we *do* define __USE_TIME_BITS64 and do so unconditionally, on all archs, including future rv32. Even if we could opt not to define it on rv32, that would not help with future 32-bit ports like sparc where there will be no redirection but __USE_TIME_BITS64 is needed to get the kernel headers to do the right thing. So if any applications are really misusing __USE_TIME_BITS64 as an indicator of having symbol redirections, they need to stop/get fixed. Rich