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 017CB1F461 for ; Thu, 18 Jul 2019 13:35:55 +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:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=DZtK 5kYFxASaWf7By+CYY3lSC5EZETOE3UDaZa+G+fJ0NKafzYraY//kMsdwo+a4nhBU e/vzrs5qjjXNYkxCYYVq0ipJCy9np6KeWOw6Zdcx7YdE+haF1HH/ujWuczdnVS3c tliEQQZlHdnWyT/QH73rQTy2cOk1Yny1Uh5pDTs= 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:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=OFWwvIyeqJ rgH34JttrKGLmnzJQ=; b=Zq0wSdN5B2IzOUhGpsYk8adUn15MvhSgvixMaJ7dx8 NxF+3xD6YcRebwgNlo2e+oEkeyI8pD4wmOM+z1kDyddPZnoZ5QHlENDr3tG4YTa4 /qIMzxzwz5yOtnkzf9JgEhY1Wjw3H8yzsPFlTfU4vcuIfCy/PFkdijVzibEJK8Ey M= Received: (qmail 60041 invoked by alias); 18 Jul 2019 13:35:54 -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 60033 invoked by uid 89); 18 Jul 2019 13:35:54 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: brightrain.aerifal.cx Date: Thu, 18 Jul 2019 09:35:43 -0400 From: Rich Felker To: Lukasz Majewski Cc: Arnd Bergmann , Wolfgang Denk , Florian Weimer , GNU C Library , Joseph Myers Subject: Re: Accelerating Y2038 glibc fixes Message-ID: <20190718133543.GQ1506@brightrain.aerifal.cx> References: <20190712072103.D3DBC24003A@gemini.denx.de> <874l3mjgi6.fsf@oldenburg2.str.redhat.com> <20190716145216.1C7CE240085@gemini.denx.de> <20190717175026.GM1506@brightrain.aerifal.cx> <20190717235748.2552834a@jawa> <20190717223706.GO1506@brightrain.aerifal.cx> <20190718092048.63b90db1@jawa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190718092048.63b90db1@jawa> User-Agent: Mutt/1.5.21 (2010-09-15) On Thu, Jul 18, 2019 at 09:20:48AM +0200, Lukasz Majewski wrote: > > > > To answer Wolfgang Denk's original question, in my opinion, the > > > > single most valuable thing for accelerating the time64 process > > > > that third parties could contribute is detailed analysis of the > > > > interfaces that will break. > > > > > > Such analysis is already done and available on glib'c wiki page > > > [3]. > > > > ...because there's no such analysis here. Such analysis is basically a > > grep -r of /usr/include on a Debian system with *-dev installed, > > combined with some automated analysis of what packages depend on each > > matching package's library, then manual analysis to determine impact > > (and in many cases, whether the lib is even a real lib that's used by > > multiple programs rather than just by the program it ships with). > > > > Arnd sent me a really preliminary grep like this a couple weeks ago, > > but doing it right is going to take a lot more time. > > Is this script available somewhere? I'm wondering if I could adapt it > (and run) to meta-y2038? See this thread: https://www.openwall.com/lists/musl/2019/07/02/2 Again, the point here is identifying libraries that have time_t-derived structures as part of their public APIs, since that means their *ABIs* are functions of how time_t is defined. There are fairly many, but there's also good reason to believe that lots of them aren't actually "public" in any meaningful sense. Assuming the list is produced correctly and is complete, updating these in sync with the apps (or other libs) that consume them avoids any breakage, and is a much smaller task than replacing the whole binary ecosystem all at once. Rich