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,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 376FE20248 for ; Tue, 19 Mar 2019 23:12:27 +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=NMIS+h1MgaSecgyD syjgDVX6VQCDj8Y2oPYeMOFtQcaW9XpW3Fjt9P6B/XsgBbjXngUS6qlN7wihVzYU 4VI67rC21R1UY38jQfLsSqv+Llc+kvR1ll/kmlXoY9o6UuF4Gr4+LKA+bX2HjZJL vpPrWXMBqWPP8LH0H3kKab4xwU8= 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=3k8MTq8QzdHdrwQfPjwVTH n/xFI=; b=EoZPnr93W1LgeBDe1JVLR7qxfgOYapl6OuSgQ7Y4a+Sebsqe4KcLIM g9L7AMQIjVL1HLH+NE9kPnRC32xkWvSnN05tkOIJFTnNUkqcTzDrNWSoPtSDGZNt eTdOh+i+oUJPUfFKjTT47Rulf8UTKaXW77IeFseGoAtHimPeKypm8= Received: (qmail 67483 invoked by alias); 19 Mar 2019 23:12:24 -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 67475 invoked by uid 89); 19 Mar 2019 23:12:24 -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> From: Paul Eggert Message-ID: <910c75f2-86ea-34cd-7279-71fcbf5edabc@cs.ucla.edu> Date: Tue, 19 Mar 2019 16:12:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190319143956.52f83a48@jawa> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Lukasz Majewski wrote: > Shouldn't we have: return s == t; ? Yes, absolutely. Thanks for catching that. I tested only the Gnulib version, and Gnulib doesn't use that code. Do you have glibc tests to catch bugs like this? If no, please add writing some tests to your lists of things to do. > In the time/mktime.c there is: > weak_alias (mktime, timelocal), which makes the timelocal calls > aliases to mktime for time_t 32 and 64 bit (for Y2038 the proper > __REDIRECT will be added). Sorry, I'm a bit lost here. How will that __REDIRECT work, exactly? Should it be part of this patch, or part of a later patch? >> Come to think of it, user code shouldn't see __time64_t either.... > > Is that the reason for removing __time64_t definition from > posix/bits/types.h ? Yes. > In the time/mktime-internal.h you added a comment regarding BeOS users > and posix time_t - do you know any :-) ? Just one. :-) See: https://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00470.html Bruno's most recent BeOS-related submission to Gnulib was in October 2017: https://lists.gnu.org/r/bug-gnulib/2017-10/msg00098.html