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 B718A1F461 for ; Sat, 20 Jul 2019 04:43:17 +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=ZyhS 5oZEnXtwPSFR8SXLkWZxEgejRPFft7b3fUmT4G1yHLknYxIG6vYWZqqxRx9qHxpE tafvobLqMmlIXzTsPeeT+lv089M7KaUstavpKXdFAnDGWcXnQ0H0cAdjTQfU2xmD +VXUlgWfI+U4A+EAWuMCbV4NzOWn/7JLyAbHY2E= 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=piHd5AHfm1 kIkLQ0xeok0PWQcfg=; b=ccIwrsxq/LB9bXztBw1GDnBz5LjKF85MMhlMuwgwGj u9+MOaayaqhxLQD5+QUaOfToN6V7Ky2KxxLx397x/M03xAWOWfFgMX7VJz988DaB hCEifi4+2UidXfHHbQznxtxFw6MSJrMHUIeQgY6rF4osSIOO2mZ4LsDy3xEferG2 k= Received: (qmail 21538 invoked by alias); 20 Jul 2019 04:43:15 -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 21529 invoked by uid 89); 20 Jul 2019 04:43:15 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: brightrain.aerifal.cx Date: Sat, 20 Jul 2019 00:43:02 -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: <20190720044302.GY1506@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> <20190718144715.GA11800@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190718144715.GA11800@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) On Thu, Jul 18, 2019 at 10:47:15AM -0400, Rich Felker wrote: > On Wed, Jul 17, 2019 at 11:57:48PM +0200, Lukasz Majewski wrote: > > Note: > > > > [1] - > > https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-11-03-2019 > > > > [2] - https://github.com/lmajewski/y2038-tests > > > > [3] - > > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?highlight=%28y2038%29 > > > > [4] - https://github.com/lmajewski/meta-y2038/tree/master > > Some findings here that need correction: > > [1] is completely missing the sysvipc interfaces affected, and [3] > fails to document them as affected because the structs are variadic > arguments not declared ones. Fortunately, this means we can get away > without actually replacing the functions, and instead define new > command numbers to perform the translation. When doing this, glibc > should follow musl and correct other bugs in these structs: for > example, struct ipc_perm's mode field has the wrong type on some archs > (short instead of mode_t; only makes a difference on big endian). Another omission I found: ftw/nftw. They pass stat structures back to a callback. If the time64 stat structures start with the old stat64 structure and just append the new timespecs to the end, no action is required here for compatibility. This is what I'm leaning towards doing in musl, but it doesn't seem to be what the above glibc branch does. If glibc is going to completely redefine the stat structure for time64, then new versions ftw and nftw are needed along with redirections for them. There may be other interfaces like this too. I seem to recall glibc having another nonstandard interface like ftw, but it being broken and not even supporting _FILE_OFFSET_BITS=64 yet, so no idea what would happen to it... Rich