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.0 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 590721F461 for ; Thu, 18 Jul 2019 22:32: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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=aaDn+xTKfXbApnAt 5mkvRgihVieKZyoP/ihwvbSr2wiYKx94w2Cy0slBJV2a1NEj93UB8bJ9Y4yTBd2O jrDkZcq9ms/TWZOAA2s7EepJwGa+sOTIULOzEGyj7uQ75AY1y86cJMUOtWiOE4KU TVWJ2KIPG0aHc+X06A93dZ5eeHg= 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=mXjKac2SqENH6BVZJq8UiA T1kdQ=; b=KvfD4nKEb/4Cwt3amKrFRAGN/16e/SHhOw48TTDe1pEJEnUkEA7K2t lPpz41fIFWlya9kNTa78WMa7XWhpfSyjC1vIxEeAu0pCe/BWq9kL8/yF5BYbz0LF Av0JTEp+VquQMmK6cvj+lZGZybR2+UV14eX/h/49UlblKO+Q5lz4w= Received: (qmail 57659 invoked by alias); 18 Jul 2019 22:32:52 -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 57651 invoked by uid 89); 18 Jul 2019 22:32:52 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: zimbra.cs.ucla.edu Subject: Re: Accelerating Y2038 glibc fixes To: Adhemerval Zanella Cc: GNU C Library 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> <87ftn3xija.fsf@oldenburg2.str.redhat.com> <0a59e20b-e941-e71a-5d4c-cda8088617c3@linaro.org> From: Paul Eggert Message-ID: <535c8c27-1c3d-8f76-2018-554e54c6edc8@cs.ucla.edu> Date: Thu, 18 Jul 2019 15:32:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <0a59e20b-e941-e71a-5d4c-cda8088617c3@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Adhemerval Zanella wrote: > I still think that in long term this initial bump transition is better > than to the complexity from mixed support. Yes, that is what NetBSD did in release 6.0 (2012). OpenBSD release 5.5 (2014) followed suit. Admittedly these are smaller ecosystems, but the transitions went reasonably well as I recall. With my application-developer hat on, I prefer this simpler approach to the sort of complexity we went through with off_t in the 1990s, a mess that we're still having to deal with.