From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAD_ENC_HEADER,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 23BDB20248 for ; Thu, 28 Mar 2019 08:59:26 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type; q=dns; s=default; b=P+iLX 1WNwp60vhVnaBVh//z1VQjwhZo/ivorZiF58dL7s6Hv4q2Re0jHgGZAzwXJCxyrj h3E4vGGZcP+JTSozauqa2K2Ady8qfwExZiaLUbSPi3oSONCK2ktipHoD6j/I/CAW Y4VK2ZI2cGyUYs0tu71Qijk8+pZni++s/CSJO4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type; s=default; bh=3YzowzOtkl6 9f4XWj5hfqNZKr7M=; b=XmtHvoypMU3JxOhwoop/vtgHbN0XIcoyuuGME7U+A75 dEFAVCS3AIeQ0kz6YEHs5xMXLS5B6zW4vQdib1uXJOC/YUiE7pwwbWoeGjvEPj1+ lUh5ogSBLnrggYnEO9RvSNzn7SVZMixLhhJGDFVYsg/KIOPse6ExpciADUi1Wh4c = Received: (qmail 20767 invoked by alias); 28 Mar 2019 08:59:22 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 20746 invoked by uid 89); 28 Mar 2019 08:59:21 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-out.m-online.net Date: Thu, 28 Mar 2019 09:59:05 +0100 From: Lukasz Majewski To: Paul Eggert Cc: libc-alpha@sourceware.org, Joseph Myers Subject: Re: [PATCH v2 1/2] Y2038: make __mktime_internal compatible with __time64_t Message-ID: <20190328095905.5900ddd9@jawa> In-Reply-To: References: <20190227112042.1794-1-lukma@denx.de> <20190312075856.33ac3c5b@jawa> <20190319143956.52f83a48@jawa> <910c75f2-86ea-34cd-7279-71fcbf5edabc@cs.ucla.edu> <20190323125906.699ce15e@jawa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/jDi.Z9_KTN1di4wqQ=78zly"; protocol="application/pgp-signature" --Sig_/jDi.Z9_KTN1di4wqQ=78zly Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Paul, > On 3/23/19 4:59 AM, Lukasz Majewski wrote: > > https://github.com/lmajewski/y2038_glibc/commits/mktime_v3_fixes > > > > In short: > > > > - The __time64_t needs to be exported to user space as it is a > > building block for Y2038 safe 32 bit systems' structures (like > > struct __timeval64). In the above use case the "normal" timeval is > > implicitly replaced with __timeval64. =20 >=20 > I looked into that URL, and I don't see any explanation of why > __time64_t needs to be visible to user code. On top of this patchset there is an ongoing work for Y2038 support: https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-__clock_s= ettime64_v1-27-03-2019 The idea till now was to introduce new "installed" glibc type: struct __timeval64 { __time64_t tv_sec; /* Seconds */ __int64_t tv_usec; /* Microseconds */ }; Which uses explicit __time64_t to store tv_sec. The above structure on 32bit Y2038 safe devices would replace in user code struct timeval. >=20 > Surely struct timeval ought to be consistent with time_t. That is, it > ought to continue to be defined like this: >=20 > struct timeval > { > =C2=A0 __time_t tv_sec;=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 /* Seconds.= =C2=A0 */ > =C2=A0 __suseconds_t tv_usec;=C2=A0=C2=A0=C2=A0 /* Microseconds.=C2=A0 */ > }; >=20 > where __time_t is merely an alias for time_t and so is 64 bits if > _TIME_BITS=3D64 and is the current size (32 or 64) otherwise. In other words - I shall not introduce new "installed" type for struct timeval and just in posix/bits/types.h define: #ifndef __USE_TIME_BITS64 __STD_TYPE __TIME_T_TYPE __time_t; /* Seconds since the Epoch. */ #else __STD_TYPE=C2=B7__TIME64_T_TYPE __time_t; #endif In that way all structures which use __time_t are Y2038 safe. ONE NOTE: I also guess that the above change keeps those structs posix compliant for 32 bit machines ? >=20 > The only reason I can see why __time64_t needs to be visible to user > code, would be if a single user source file accesses both time_t and > __time64_t (or needs to access both struct timeval and struct > timeval64, or similarly for struct timespec etc.). The only supported use case would be that user defines -D_TIME_BITS=3D64 during compilation of the SW (in OE/yocto) and use Y2038 safe types. > However, we should > not support a complicated API like that, as it's typically not useful > in practice and its mere availability causes more confusion than it's > worth - as I've discovered with _FILE_OFFSET_BITS and __off64_t. If I may ask - what were the biggest problems? I would appreciate if we could make the decision/agreement on this - if the 64bit time support shall be done by above redefinition of __time_t and not "exporting" __time64_t (and struct __timeval64, __timespec64, etc). > Instead, glibc should have a simple user API where _TIME_BITS=3D64 > merely says "I want 64-bit time_t everywhere" and a module either > uses this option or it doesn't. >=20 So according to above I shall only introduce glibc _internal_ struct __timespec64/__timeval64 in include/bits/types/ : #if __WORDSIZE > 32 || ! defined(__USE_TIME_BITS64) # define __timespec64 timespec; #else struct __timespec64 { __time64_t tv_sec; __int64_t tv_nsec; } #endif and rewrite the relevant functions/syscalls (like clock_settime() in this particular case) to use it in glibc ? PROBLEM(S) with internal struct __timespec64: - Would be misleading for 32 bit architectures (minor issue) - Needs to met specific Linux kernel's ABI as it is passed as an argument to Linux syscalls (like clock_settime64). > I did see a fix in that URL, to use "#elif defined TIME_T_IS_SIGNED" > instead of "#elif TIME_T_IS_SIGNED" for the benefit of picky glibc > compiles, and that fix is incorporated in the revised patch attached. >=20 Thanks for the revised patch. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de --Sig_/jDi.Z9_KTN1di4wqQ=78zly Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAlycjNkACgkQAR8vZIA0 zr1P8AgAg5jhQwspIvpgcPajwwD7KnHkEZDjhqfXHakQoxLDsl3ojux9KQ2jOlI+ 2uzhANX8vcnivT4d2EPKJzw4UdhSNLN2q9YbmWf8Ti3aQMnJ5KmK4Tfexemjy1cR NL1YTG0KhA3gxnMfNzPX+lxb1ZGy77qvmuF6xkukA2GKTGPLebO+qqxTYuBukrM8 ngcuLXMjzBS94PLMm+PLa4fpf8XsLEFM2G4Z4iE/eDKVd6a295Xb0IL00FK74DiI ewvaPVv4YOhSgiiAnVUoaNtgSXxJgMWeOVViMmWVsavtaW/9HLMqA2eBd5Bhkw/2 PGTP1arLM36AzBEfq/Ft3Vb89Yzv6g== =0YGC -----END PGP SIGNATURE----- --Sig_/jDi.Z9_KTN1di4wqQ=78zly--