From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id C7945AF2 for ; Fri, 9 May 2014 17:30:58 +0000 (UTC) Received: from mail.zytor.com (terminus.zytor.com [198.137.202.10]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7ADBE20314 for ; Fri, 9 May 2014 17:30:58 +0000 (UTC) Message-ID: <536D10C2.5070907@zytor.com> Date: Fri, 09 May 2014 10:30:42 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 To: Josh Triplett References: <5367D989.1000504@linaro.org> <20140505205339.GB15815@cloud> <53684526.7060507@zytor.com> <20140506022158.GA1499@thin> In-Reply-To: <20140506022158.GA1499@thin> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: John Stultz , ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [CORE TOPIC] Dealing with 2038 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 05/05/2014 07:21 PM, Josh Triplett wrote: > > 64-bit off_t support seems like a similar issue; all the kernel > interfaces support 64-bit off_t, and glibc has #defines for > 64-bit off_t, but a large number of userspace programs don't bother to > define them. > > That seems like the right path to transition time_t as well. > The transition to a 64-bit off_t was still enormously complex, which involved defining entirely new types and APIs which were then optionally #defined to the traditional names. Hence the _FILE_OFFSET_BITS opt-in. For time_t it is even worse. -hpa