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 57F041F462 for ; Fri, 26 Jul 2019 13:01:58 +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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; q=dns; s=default; b=HD726 NBDhg0LVzucmQmXsK1PWDeTsnZIfuWih49zlEElEGL0WIgdPDWyO2gDYPGD/8HkI jmU/2+WdkjBji4blZK8gw8fQpREoGa88LRMq9fSw1rrd/4mWnK8BbygsalWOswC3 oeESclq0AlX2mZYrMnyzOhsIoY1W6QD7V5wd5M= 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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; s=default; bh=3vwW1X1abjs QdXxVy7fnXVWJVD8=; b=RMOox/ZyUM+tQBmpatQyM0Wg7RouBCOgAJpmf+rZEXd KBemoG7OxmNJiL6E8G1goHrkxtbNzP1leGmdLtTM/z8AHPkS9A4PdoLksg3n/QsK 3Y+PzZd6KkTZPGIw5xW2aBWsLTvOpWvYVHFm+f5geMV2GlLc0PQfiUfXCNdV/JMs = Received: (qmail 39531 invoked by alias); 26 Jul 2019 13:01:56 -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 39523 invoked by uid 89); 26 Jul 2019 13:01:56 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Arnd Bergmann Cc: Zack Weinberg , Paul Eggert , Alistair Francis , Joseph Myers , Alistair Francis , GNU C Library , Adhemerval Zanella , Palmer Dabbelt , macro@wdc.com, Zong Li , Zong Li Subject: Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable References: <4ec24dc5-ca74-82cd-5116-c6d76688765f@cs.ucla.edu> Date: Fri, 26 Jul 2019 15:01:48 +0200 In-Reply-To: (Arnd Bergmann's message of "Thu, 25 Jul 2019 20:53:17 +0200") Message-ID: <87lfwlar0j.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain * Arnd Bergmann: > On Thu, Jul 25, 2019 at 7:21 PM Zack Weinberg wrote: >> >> On Thu, Jul 25, 2019 at 1:03 PM Paul Eggert wrote: >> > >> > Arnd Bergmann wrote: >> > > If we want to keep >> > > the traditional settimeofday()/gettimeofday() behavior working, a new >> > > kernel interface could be added >> > >> > Let's not. That behavior was a bad idea even in the 1980s, and applications >> > stopped using it decades ago. It has been completely obsoleted by TZ strings. >> >> Do we think we could get away with having both functions fail (with >> EINVAL) whenever the tz argument is non-null? > > From my findings at Debian code search, I found code like > > struct timeval my_gettime(void) > { > struct timezone tz_ignored; > struct timeval tv; > gettimeofday(&tv, &tz_ignored); > return tv; > } > > In this case, the safer choice would be to silently ignore it. > > Another alternative would be to hide the definition of 'struct timezone' > in the libc headers and only leave a forward declaration. Renaming the struct timezone members might be sufficient. Then the code above would still compile, but something that actually depends on the struct timezone data would not. Thanks, Florian