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,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 A8ED320248 for ; Sat, 30 Mar 2019 14:39:24 +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=LSHlW cvqRxjhK8kCsqJMLXmHTUKcK7XvBCmc06Ghy2bsr+HkdtQ+PQhfUpmp10gKfHGK/ MwZAK6DMkDISN6ThOMFz8UgnXmfcsfkDX0NZPEQa1gJWVzQlA/BLshoL5qVh+DHH zR8IDBK9mf5jGGzKX/xlnB8t8SYlWbjLU+7U2Q= 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=xPVqVLZ5UnR sy/g94enG/K5vZg4=; b=Wqpc8eaHKcBBSJwEx72LDsxq2hYtQlVIV10Nuo/g9ao dwqt19wtkSPdsU6p36vYrJhMLAG0zM3rokM964x0v0VJgAyyx+r4HSU2m4XgSsaO uJk5PjyldsGhSMnTOm+8CvEkOdtEIDBd3eux0N53ZjO73UF2RZjJhcvp7/11oV4E = Received: (qmail 90028 invoked by alias); 30 Mar 2019 14:39:21 -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 90013 invoked by uid 89); 30 Mar 2019 14:39:20 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-out.m-online.net Date: Sat, 30 Mar 2019 15:39:00 +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: <20190330153900.0510f73c@jawa> In-Reply-To: <2e5d75ad-2152-fc8f-2a98-892880dd0097@cs.ucla.edu> References: <20190227112042.1794-1-lukma@denx.de> <20190312075856.33ac3c5b@jawa> <20190319143956.52f83a48@jawa> <910c75f2-86ea-34cd-7279-71fcbf5edabc@cs.ucla.edu> <20190323125906.699ce15e@jawa> <20190328095905.5900ddd9@jawa> <20190329152452.19d7b78c@jawa> <2e5d75ad-2152-fc8f-2a98-892880dd0097@cs.ucla.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/BFeAtdSLQW3n/mTz_uHCFx_"; protocol="application/pgp-signature" --Sig_/BFeAtdSLQW3n/mTz_uHCFx_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Paul, > On 3/29/19 7:24 AM, Lukasz Majewski wrote: > > With __timespec64 exported (installed in usr/include/*) - there > > would be an explicit type to show that we are Y2038 safe (when e.g. > > debugging). =20 >=20 > That's not much of an argument for exporting __timespec64 to user > code. When debugging a module, a developer can easily determine > whether whether time_t is 32- or 64-bit by printing sizeof (time_t) > in GDB, so the visibility of __timespec64 wouldn't give them any > information that they don't already have. Yes, indeed. From practical point of view it would be best to avoid introducing any new types. >=20 > > I do have a setup where only for glibc compilation I do disable > > -D_TIME_BITS64, but for _all_ other source code it is enabled. =20 >=20 > Sorry, I'm not following what you mean by "disable -DTIME_BITS64". Do > you mean that you compile applications with -D_TIME_BITS=3D64 and > compile glibc without it? Yes, exactly. That was the case when I last time was trying to use/compile the glibc being Y2038 safe and as the only libc on the OE/Yocto created system. However, it was some time ago (before I did some cleanup) The meta-y2038 relevant branch (but it is outdated now a bit): https://github.com/lmajewski/meta-y2038/commits/y2038-glibc2.29-deploy >=20 > Does -D_TIME_BITS=3D64 affect building the GNU C library itself, and if > so, why?=20 I did not checked it with the new code, but yes the glibc was not buildable with -D_TIME_BITS=3D64 > (Of course -D_TIME_BITS=3D64 will affect glibc's auxiliary > programs like zdump, but these are exceptional cases; I'm worried > about the library proper.) I thought _TIME_BITS was intended for use > in user programs, not for use in glibc itself. Yes, exactly. The _TIME_BITS shall be only supported when building user programs. Glibc shall not be build with it. >=20 > The answers to the above questions should be documented in > manual/maint.texi; could you add that to your list of things to do? >=20 Yes, noted. 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_/BFeAtdSLQW3n/mTz_uHCFx_ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAlyff4UACgkQAR8vZIA0 zr11bQf+JNkGga89l/2ZQ+XiRbEeDJ8QGe/NhbMGjGawp/QMp8gmgG/TvWyapmoZ /8mOQBP784Bj5NzyBKA7NovOyJ4l22rmOZ/tNVzxJCV8nxgIpTo/YWPZy9C/oFZm atyEvzJ6ySMfgEf0mBJ8EebhWz1NJ+LQYQuKQ5L/vTx5aF1zeZuw0B+8XxzlUKSk o/KCEaxMmvbx0bfOtnq6mz2YDBGUBqmjGyy/Tk1mFZ1A0HXxxfPTrRcT+BRZ/esQ DUzKZmvQpCqs1VrESD2LWeKSqyJJRmbDoXOJl7PKkg6fO9dFihnwgtPfslMTwaBN XzULRQMME/1XgfJh555okfGaxSjNrA== =WtSS -----END PGP SIGNATURE----- --Sig_/BFeAtdSLQW3n/mTz_uHCFx_--