From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87375 invoked by alias); 22 Jun 2016 20:19:58 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 87343 invoked by uid 89); 22 Jun 2016 20:19:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Date: Wed, 22 Jun 2016 20:19:00 -0000 From: Joseph Myers To: Arnd Bergmann CC: , Albert ARIBAUD , Y2038 Subject: Re: Fourth draft of the Y2038 design document In-Reply-To: <6204150.Ja8izhmCjv@wuerfel> Message-ID: References: <20160622005838.60a95c44.albert.aribaud@3adev.fr> <4435377.8hJ2GQPYUg@wuerfel> <6204150.Ja8izhmCjv@wuerfel> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-06/txt/msg00868.txt.bz2 On Wed, 22 Jun 2016, Arnd Bergmann wrote: > We can avoid most of the problems if building with _TIME_BITS=64 > has no effect unless both glibc and the kernel headers are new > enough to provide the definitions for 64-bit time_t. That way > we can at least ensure that calling an ioctl command or setsockopt > with an incompatible ABI will result in an error code rather than > wrong data. I'd be a lot more comfortable with requiring new kernel headers to build and use glibc than with requiring a new kernel at runtime for _TIME_BITS=64 to work. New kernel headers are one of the easiest things to use when building glibc, since we have the --with-headers option. (In fact right now the headers requirement (3.2) is newer than the runtime requirement (2.6.32) on x86_64 / x86.) (_TIME_BITS=64 should of course be an OS-independent API, supported for all glibc configurations. Obviously exactly what Hurd does is up to the Hurd maintainers, as probably is fixing Hurd to keep it working with _TIME_BITS=64, but _TIME_BITS=64 should clearly enable 64-bit time_t for it even if some underlying Y2038-safety is missing. NaCl already has 64-bit time_t so _TIME_BITS=64 would have no effect there.) -- Joseph S. Myers joseph@codesourcery.com