From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-68242-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 59045 invoked by alias); 21 Mar 2016 12:15:31 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 58952 invoked by uid 89); 21 Mar 2016 12:15:30 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=1.1 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=cordialement, albert, Albert, bonjour
X-HELO: smtp2-g21.free.fr
Date: Mon, 21 Mar 2016 12:15:00 -0000
From: Albert ARIBAUD <albert.aribaud@3adev.fr>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: Second draft of the Y2038 design document
Message-ID: <20160321131520.6c27251e.albert.aribaud@3adev.fr>
In-Reply-To: <56AA8465.5040803@cs.ucla.edu>
References: <20160128204114.6c7dbbf7.albert.aribaud@3adev.fr>
	<56AA8465.5040803@cs.ucla.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-SW-Source: 2016-03/txt/msg00522.txt.bz2

Bonjour Paul,

Le Thu, 28 Jan 2016 13:13:09 -0800, Paul Eggert <eggert@cs.ucla.edu> a
=C3=A9crit :

> Some typos: "1901-12-13 19:55:13 UTC" should be "1901-12-13 20:45:52=20
> UTC". "sentive" should be "sensitive". "20338" should be "2038". "Thins"=
=20
> should be "This".

Thanks, will fix this.

> I don't see why functions like 'time' and 'gettimeofday' should be=20
> allowed to misbehave on 64-bit hosts after 2038. They should just work.=20
> Glibc should not worry about 64-bit kernels without 64-bit time support.=
=20
> Any such kernels should just get fixed before 2038 rolls around.

What about using GLIBC used over a current 64-bit kernel version, which
does not have proper Y2038 support, which makes GLIBC unable to provide
correct time-of-day past Y2038?

Should this GLIBC/kernel version combination be considered forbidden,
IOW, are we saying a Y2038-proof GLIBC should only be used with a
Y2038-proof kernel?

Cordialement,
Albert ARIBAUD
3ADEV