From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 1DD2E3858415 for ; Fri, 5 Apr 2024 13:33:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1DD2E3858415 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 1DD2E3858415 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::62c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712323998; cv=none; b=Ki2jXHZE8ZJ0XT6LeCxmFoz2E4p3K9VAj70X6wP9J00bkZL6KfJFeBIBU+BFzR2MSjIvDFN2kp+6CYuH7IwQdtXjU985QmMs971dKarpWoW6bQC/P5FNkE4V6i+jqdaabny2X/5/bDEn4aN+jjaJMQrCgDuHEUzfS+wt6Kd971c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712323998; c=relaxed/simple; bh=w+HSKdZNEOtjqqZkrfnWy5Rp8fgPJTgwbLlQWdXazt0=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=EWRRpBR8/7Mun/wBeqge4j1LmDRFu5hei/BNG7NX9LvAvCra1nzTjFFsVRfel584PRE0JV5msnY68D5OjTQFFJjNa9viOndDwTI5eVEWxNPNhtNVmFWb+91Rgq42wClDJBJCY3a7xq9k3y5qPtFeiCs7+LZ8Ki7KBUekF8c9fzw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1e2a7b5ef7bso16925605ad.1 for ; Fri, 05 Apr 2024 06:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1712323995; x=1712928795; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Bi0VO3lWjIJNU0QHynPfmHN9O5QVLzvQiSIV2vUkY/E=; b=hO1lGopmImufx76Kx/UYqpO95GlV8jGtXWtHqSCyxdEL5zD8QxSNS773ZHuebDQzUR JXWT6hNV8LKbaMmLdgg8Z/QgFDDq8vV8+CDKoGazIFsNsxaPEH47dtR1medxSV16ZVz2 mjEu9WvIQ+m/3d8OFrnlnzeOuXRwzLQ+OGXn0LyAgaYhkIrVHo3f8q3w3hCrXBv2jQJh Sqk01rqnHsg9T+6pfXtrcFARV52C5NOSorj8CVybCO7SdiKrmPt1ckVOYyopYLGMeJ1H pKwOnRNNy/SP5fGKNfvAa24GLmM+v2nmqPxNV1mfjnU7TzwEg/BROKEfOvFVPZwN7gR/ eGoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712323995; x=1712928795; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Bi0VO3lWjIJNU0QHynPfmHN9O5QVLzvQiSIV2vUkY/E=; b=s+Tlde1S2dX/YTxUwiOQB/ZStm9GhvpXhBwi4pKc0ZgmnUEXlAt0HprFXHrqwceFgU TpVf9ezrXfGcsZoVfQm6RZU2rLDVsRMa+p+Gt01idV7YfrLQh+FV1WKmwoh/Ebvnmyhf jCUREEvPtsE8Y0Ab1dcPm8zpfXKQ0X9crsR/FXjM3epFRFIHBPwx08I5OwRJ3sT5A1KX rgVnetfOmNt3cT0aewqTKTMTv26mFd0vM/bDPEDBwekH0jxzhAL8hZ3woaTfiuKtFSLe fey9hjBt/SsVojNel3/WNX62DCHWXyOWPDMN19EyOC2uYXnXoy6LOwdQopL7ShUXT88i 5JTQ== X-Forwarded-Encrypted: i=1; AJvYcCUz7e7GbBHcVgBeN333SWvHcyYQlqT5P30cQ8ZijV/zc4bR2g/5GuBBZKS3tT5d6rXri6ycvsmP19TV6iNB5aVMZPvwsnkGN/Zf X-Gm-Message-State: AOJu0Yyk3h4RNL9WeaQWnH8AKKOvA3halO02KCzgALn6Itc2ys9l/iAx 7EjhGJH+RQJ/KmX+d4jbCvMCKzvLfLL0EMPqDnhMh0QLBN0bAfHc/hCNWvEd1xto8a5GFE3rSBL 3 X-Google-Smtp-Source: AGHT+IHkcBIFQSBQAUOAITZgdhYIxMov+WKum3sLddG0/6R1FadOCeqfKro6DN+4snTeN9vHIi6v/A== X-Received: by 2002:a17:902:f551:b0:1e2:75a3:685a with SMTP id h17-20020a170902f55100b001e275a3685amr1387017plf.12.1712323995035; Fri, 05 Apr 2024 06:33:15 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:3e7e:1da:fede:338:8975? ([2804:1b3:a7c0:3e7e:1da:fede:338:8975]) by smtp.gmail.com with ESMTPSA id jj20-20020a170903049400b001dee9d80bdcsm1547423plb.107.2024.04.05.06.32.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Apr 2024 06:32:59 -0700 (PDT) Message-ID: Date: Fri, 5 Apr 2024 10:32:57 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] login: Use unsigned 32-bit types for seconds-since-epoch To: Florian Weimer Cc: Paul Eggert , libc-alpha@sourceware.org References: <87sf02guiz.fsf@oldenburg.str.redhat.com> <6289d40a-7989-4869-8f47-553263e4df7a@cs.ucla.edu> <87jzld7lz8.fsf@oldenburg.str.redhat.com> <7399c560-3565-4b8a-b3ae-360fe074941b@linaro.org> <87r0fk0y6a.fsf@oldenburg.str.redhat.com> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <87r0fk0y6a.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 05/04/24 09:52, Florian Weimer wrote: > * Adhemerval Zanella Netto: > >> On 04/04/24 02:09, Florian Weimer wrote: >>> * Paul Eggert: >>> >>>> On 4/3/24 11:39, Florian Weimer wrote: >>>>> For consistency, >>>>> if there is a 64-bit architecture that is coinstallable, define >>>>> __WORDSIZE_TIME64_COMPAT32 to 1 on the 32-bit architectyre as well. >>>> >>>> Could you explain the advantage of consistency here? User code almost >>>> invariably assignes ut_tv.tv_sec to time_t (this is true of every >>>> instance I found of ut_tv in Gnulib source code, for example). So >>>> changing this field's type on platforms where time_t is 32 bits will >>>> likely be ineffective in practice, and might cause more problems than >>>> it cures. >>> >>> Few applications with a 32-bit time_t will work once there is a value in >>> this field with the MSB set. So the relevant case is applications that >>> were built with -D_TIME_BITS=64, and there the consistent behavior with >>> the 64-bit architecture helps. >> >> This helps only architectures with __WORDSIZE_TIME64_COMPAT32, so it does >> not really solve the issue for all legacy platforms. > > We can add more __WORDSIZE_TIME64_COMPAT32=1 definitions. > >> I still prefer if we just deprecate this whole interface, since from >> other legacy ABI history (non-LFS interface) programs will keep using >> it until something breaks. > > I don't disagree, I just want to give distributions the option to > backport a reviewed patch with a workaround that appears not to require > much application porting. I believe many of us are preparing toolchains > for distributions that are running close to the 2038 cliff. So maybe add deprecated on utmp/utmpx functions, along with a NEWS entry stating these function will make noop in future glibc release?