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.1 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 1588E20248 for ; Thu, 28 Mar 2019 16:10:03 +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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=x2Ec+mYXxUisG3kq u+os6I+3cLfveWYk26oo6Xe1n1mXOhl2nus8KJ1fPJPjWMj+g0mcxj6XFU2iu6OT xGauA3gq2PK13CfddfhUl3dccwxgCdTsF2P9iEeMk5aOkFqXYe+i1n2yt+ZsN9/X Cbvf9LTmCWWQPXJrWBFZKbApGH8= 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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=wUr9OsMFiIDiGVx9QvnHwy 2ZJLE=; b=FDKwgbdZEnAuPAVQnwFXEdKBR5iJzeGrMI2hSROvVnuRslLH0tQBrl VAJIhnlTnmsnazdEeTgb6+A0+DdVwksgug68QsA22QS2rnGNdR1BqlEo9FnoHUtL EAW3+7jpekN3Beb9GbIR8/Tc7p+2PUWKU++wARPTOxSJsCXthZBpc= Received: (qmail 84400 invoked by alias); 28 Mar 2019 16:09:59 -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 83708 invoked by uid 89); 28 Mar 2019 16:09:59 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH v2 1/2] Y2038: make __mktime_internal compatible with __time64_t To: Lukasz Majewski Cc: libc-alpha@sourceware.org, Joseph Myers 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> From: Paul Eggert Openpgp: preference=signencrypt Message-ID: Date: Thu, 28 Mar 2019 09:09:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <20190328095905.5900ddd9@jawa> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/28/19 1:59 AM, Lukasz Majewski wrote: > 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 ? Yes, that's the idea. > >> 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? The biggest problem is confusion and complexity. For example, see /usr/include/zlib.h (assuming you have zlib installed). zlib is one of the few libraries that tries to support both 32- and 64-bit file offsets in user code. Almost nobody understands how it is supposed to work, and I'm not sure that it even does work. And even in code that doesn't attempt to support this sort of thing, there are still problems. See, for example, the comedy of errors in where people suggest monstrosities like -Doff64_t=3D_off64_t to work around compilation issues with the Apache Portable Runtime. Rather than go down those rabbit holes, it's better to say that the entire program must be compiled consistently, i.e., one must compile all libraries with -D_TIME_BITS=3D64 if one plans to use -D_TIME_BITS=3D64 in user code that passes time_t to these libraries. This includes OpenSSL, GnuTLS, Kerberos, Glib/Gtk, libpng, ImageMagick, etc., etc., as all these libraries expose time_t in their APIs. And it's not just libraries: for example, one should compile Python with -D_TIME_BITS=3D64 and all Python modules requiring native code and using time_t in their API should also be built with -D_TIME_BITS=3D64. Although it'll be a real hassle to insist on -D_TIME_BITS=3D64 everywhere= , it's the only approach that will really work in practice. That's life. Frankly if it were up to me, I'd make 64-bit time_t the default and ask people to compile with -D_TIME_BITS=3D32 everywhere if they have backward-compability concerns, as this will be much better in the long run, and would help us avoid many of the issues we ran into during the off_t debacle. >> 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. >> > 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 No, these internal interfaces should not be in any file installed under /usr/include where users can find them and get confused. They should be only in .h files that are private to glibc and are not installed. A logical place for them would be include/time.h. > > and rewrite the relevant functions/syscalls (like clock_settime() in > this particular case) to use it in glibc ? Yes, implementations of syscalls can use these internal interfaces. > > PROBLEM(S) with internal struct __timespec64: > > - Would be misleading for 32 bit architectures (minor issue) I'm not sure I understand this point. How would we be misleading users by keeping the __time64_t interfaces private? > > - Needs to met specific Linux kernel's ABI as it is passed as an > argument to Linux syscalls (like clock_settime64). Yes, internally glibc will need to know what the kernel ABI is, and do the right thing. This should be reasonably easy to do if the internal glibc interfaces are 64-bit, which they should be.