From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by sourceware.org (Postfix) with ESMTPS id 0B5FE3858D38 for ; Tue, 16 Jan 2024 16:29:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0B5FE3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0B5FE3858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::32e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705422600; cv=none; b=swGlUdqBt6ua9zpGG0HBzBEi+Wuu5nj0qtjjgx3enDk4V/nE8yUdHnwYElpXEMRPt3Yl8tepDWiuWI/vbHs8SyEb4f16z6usYodWhgc0wOquAS7TDcNSirJ0qUkfdsR3TPn7HCfTKa9KPBMxf0TfXvzzCTHUMgyCVPTZMXtXLUI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705422600; c=relaxed/simple; bh=I884jTcTpRlYvvX+g/1qTffpEHjYYKszIEwvoIjTdls=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=PfSoyqM1VjGq1VgRBWwQgJeFXwQg50wX0JYAKvoYMmSnhDh/H+4kTRECDaBPVKCk+vZSouSGuRaAVooj6Gj65u+iWQrs4uGFwhiqAfQLam7Uv+rypG+/1M03OiWv4X6OakHa7FjJMm4bJQsmzXNw4kuDX85SGxQHcn/5AGNzMyA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-6dddba43d70so4963518a34.1 for ; Tue, 16 Jan 2024 08:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1705422598; x=1706027398; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=YTV6IdY3HDjUmti3mXHegGzZsS5NkUhgBhtav5Imi4o=; b=Ba9kB99burvYzsuuQX0CLy7lULhiWXbizFrNEzfcaVIyn77CL/ovmKB2ygf0Q4/V5y ba2ZX5Y3WfyHnxDVfze+TrY+F/ZA+KC+l0JNl7DyWnn9xMRNA7kb/Q2ZZPUVEIx1smfJ EeRLCtamfrTrlpAV/HLLdkNu7j7RkgoYFi+TeF0Y/R+mLGZ8V+rI6unz72aWF7cPd3+7 EFF7urN2HQ+5dH7u8VoTjfQNlvYis4LeWOpfzPpbZF4nKroHgFCr8M0hhx12KQR52f79 c4GE2PGL13LiMgeJhtJf7yvANTB8inFJO0QcRPSHDafHgBD9SeJ23LHzAAbDsB5PtIt5 8i9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705422598; x=1706027398; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YTV6IdY3HDjUmti3mXHegGzZsS5NkUhgBhtav5Imi4o=; b=jja08U34ymml4/f3yp5qyd5T18pT4V5aoOWx1rJRyPXUOQOVlR4OETY3f2RBSDRcvl apqo+4Yk42JwturSZ0SqzBcYsC41iTltfODLtcQC1gBoR3btJR0iJJmVYhYFGPZ27D8c TDpxz9B7G0XZI3INNycOpVC6dlDUYwpXW53papHo6ZOzT99tt2zx4w4qkMnR3BRMW+/N 97B2nMGmzrO9bCtHtGSeGs4Vv24zvA3IGR40KTHWdt0vGBiYmLymue3DQibKIT+0VRdM Afn+XqIF5u/fWVXxx0WJvGhISBYKh584rIUVNMCz0SAjKWfRPUPIGv6CECGMu+UNx8/B TViA== X-Gm-Message-State: AOJu0YwXYWxyjM2a1SW2yBnArUL5pEAEOXDQON6o904uVRrWcNaD/1As K2i90/ubB+4FmzxGfvPIYHdb2wGZX66Qxlxq/hTxxUtb0xg= X-Google-Smtp-Source: AGHT+IFMyiAS45pt5cN1sfEqYRL8X0R3EnWMqNOkYybzNK1MfOb8swHsO7UOk9j+oLR08jC9x3Oi+w== X-Received: by 2002:a05:6870:5253:b0:208:967e:6576 with SMTP id o19-20020a056870525300b00208967e6576mr4960561oai.25.1705422596220; Tue, 16 Jan 2024 08:29:56 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c2:2787:344c:b1eb:d47b:fe5e? ([2804:1b3:a7c2:2787:344c:b1eb:d47b:fe5e]) by smtp.gmail.com with ESMTPSA id l11-20020a633e0b000000b005ceac534e47sm10306596pga.51.2024.01.16.08.29.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jan 2024 08:29:55 -0800 (PST) Message-ID: Date: Tue, 16 Jan 2024 13:29:51 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: 64 bit time_t on riscv32 Content-Language: en-US To: Florian Weimer , Rich Felker Cc: Antonios Salios via Libc-help , Antonios Salios , Jan Henrik Weinstock , =?UTF-8?Q?Lukas_J=C3=BCnger?= 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> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <87r0ih1c4g.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,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 16/01/24 13:22, 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). A possible fix would just check the redirection with if __USE_TIME_BITS64 && __TIMESIZE == 32 The code is already poking an implementation detail, so it can just continue to mimic what the installed header would do.