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=-3.9 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 0D0B51F462 for ; Thu, 25 Jul 2019 20:40:40 +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:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=YEXRj fWXuEYZWvF7Ao6AmoNUwb/kPRBTzgMX4HJ4ryGY08K+ysCJGrJxp7Fx1alqISiEJ NAMF/zRiL/7icODCFpjnF+2Si18dRMQusAslWXiUdimx+gon1AjFVAcerwJZ7JpA 7FqRhDlpTZJG2NJrgxITg2RD5Jm/eJxYzfC47g= 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:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=Zl8H8TmCXjn VkUL6jO3DWFyNqUE=; b=kBKnitjHgKZ2+l5kv7t398awTjRiCHJb0NdNbcNtnNM j+0c0Pajn4a6keXcCzYQa8iXVDyoeNsjX45nSih6WpOZrah4rFEaf81ZFcBXF+1p ulj/vOGQgM6N+ClsyvH4zPviXb8+zZ69mRabBow5Bp2IjaPu6auheD8HEhMHEAXs = Received: (qmail 105710 invoked by alias); 25 Jul 2019 20:40:37 -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 105698 invoked by uid 89); 25 Jul 2019 20:40:37 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: relay1.mentorg.com Date: Thu, 25 Jul 2019 20:40:24 +0000 From: Joseph Myers To: Adhemerval Zanella CC: Subject: Re: Accelerating Y2038 glibc fixes In-Reply-To: Message-ID: References: <20190712072103.D3DBC24003A@gemini.denx.de> <874l3mjgi6.fsf@oldenburg2.str.redhat.com> <20190716145216.1C7CE240085@gemini.denx.de> <875zo0911b.fsf@oldenburg2.str.redhat.com> <20190717160021.75EB224003E@gemini.denx.de> <87h87k7ilf.fsf@oldenburg2.str.redhat.com> <20190717181811.5902cd5e@jawa> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" On Thu, 18 Jul 2019, Adhemerval Zanella wrote: > So what about to not add a user-selected way to set the time_t size > (as off_t) and just enable time64_t support and sets is as default for > build with a minimum kernel of v5.1 (if I recall correctly as being the > one that added time64 support)? I think duplicating ABIs like this is a very bad idea - the ABI supported by glibc for a configuration that currently has 32-bit time_t should not change to have two different, incompatible variants depending on how glibc is configured. The default API provided by glibc should also not vary like that depending on how glibc is configured. Given that you have compatibility with existing binaries (as opposed to a complete new incompatible libc.so.7 ABI with building libc.so.6 for that architecture ceasing to be supported by glibc), eliminating support for building with _TIME_BITS=32 makes the changes much *harder*, not easier. There are three logical steps in the time_t transition. (a) Support building applications for 64-bit time_t, using _TIME_BITS=64. (b) Change the default to _TIME_BITS=64 (also requires defaulting to _FILE_OFFSET_BITS=64). (c) Remove support for building applications with _TIME_BITS=32. The hardest of those steps is (c), not (a), because of the difficulty in both building and testing all the compatibility symbols after step (c), without all the header redirections of symbols getting in the way when building those functions and the tests for them. In view of the difficulty of both (c) and (a), it clearly makes sense to separate them, and start with (a), with (c) to follow some time later. > I also wish we could also move forward with off_t and set LFS as default > as well. We can (it's the equivalent of (c), not of (b), that's particularly hard, though even when doing (b) you need to be careful you keep sufficient test coverage for both function variants). See what I said in . -- Joseph S. Myers joseph@codesourcery.com