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=-2.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_GMAIL_RCVD, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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 0F1211F463 for ; Thu, 19 Sep 2019 22:01:39 +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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=LgyH xMUJ1cT2AuyI/SK3W1OgKoEFag4lazqYYvp5zayuVtCf6OFVVI2ekQZjMrNFrN7s yhxRgikJeEf6i02B0P+KRj6r/NBnb14+ysNNWxaTF2z+r4dVpFhsaa9jycBahKaO b2C+ZBHbEx38oljYBD8huXUzYc/aKjCm1waFvr8= 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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=MaKfbcSXe5 qysfQtXCI6iA0y1O0=; b=VwkxiXHFVOjdY+7+IT7nVnD1IzTZfSr7ILBvjoftx9 mHVfFujylniYJFxHPq3xy25e5YCIjf5pplYyzjKRsQ6LNtBsKzumdOIGKpjRDuoj RC7fLI6uyQT0HkVvswEnmpPpCE4VNgINSwZBj7S9zKlNe8ABiulj0zLX30FU73gC 8= Received: (qmail 26314 invoked by alias); 19 Sep 2019 22:01:37 -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 26303 invoked by uid 89); 19 Sep 2019 22:01:36 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-lf1-f68.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kqLtFN17CzN1hOBo24uxF+MtQ2SGJM5DkuLXUveRN+I=; b=AgdtZ14HQzkTObuoQoRIqGFFFrkMMkaKwbR1BYTPf5u3D7dPt5Ty54uKMY0WbO5a0n xMw1jBMmFdoPhIpZ6a2fQRgjkfENIFoS1b0a83j9n0Fw+LaIAup3GYi6tNRC0XJ0BCl6 Qpw5yhLAsDaYpZMQxO8x11MWoHzoO7XQFXwfg5N2njMDQQJB0S8ALFUtipn/EPtfhCS/ JKqCxYwmlw8qbT8iF28hvL3NdIJjDhBDw+WP0dDlS9Y9Tr4PeiB/gtYGe7L4DM3lQTGF JEpRNxwqn9fPwudUkeBjxEyxK6dwGpuX+ElgSpJ36EntnDGSva1ubtrUSHwKTsuN3/5n VDWA== MIME-Version: 1.0 References: <20190906145911.30207-1-lukma@denx.de> <20190917121151.01629dad@jawa> <20190917175343.01715554@jawa> In-Reply-To: From: Alistair Francis Date: Thu, 19 Sep 2019 14:56:59 -0700 Message-ID: Subject: Re: [PATCH v7 0/3] y2038: Linux: Introduce __clock_settime64 function To: Joseph Myers Cc: Lukasz Majewski , Zack Weinberg , Arnd Bergmann , Alistair Francis , GNU C Library , Adhemerval Zanella , Florian Weimer , "Carlos O'Donell" , Stepan Golosunov Content-Type: text/plain; charset="UTF-8" On Wed, Sep 18, 2019 at 10:25 AM Joseph Myers wrote: > > On Wed, 18 Sep 2019, Alistair Francis wrote: > > > +#include > > > > /* POSIX.1b structure for a time value. This is like a `struct timeval' but > > has nanoseconds instead of microseconds. */ > > struct timespec > > { > > __time_t tv_sec; /* Seconds. */ > > +#if __WORDSIZE == 64 \ > > + || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64) > > __syscall_slong_t tv_nsec; /* Nanoseconds. */ > > +#else > > +# if BYTE_ORDER == BIG_ENDIAN > > + __int32_t tv_pad; /* Padding */ > > + __syscall_slong_t tv_nsec; /* Nanoseconds */ > > +# else > > + __int32_t tv_nsec; /* Nanoseconds */ > > + __syscall_slong_t tv_pad; /* Padding */ > > +# endif > > +#endif > > The padding must be an *unnamed bit-field* so that { tv_sec, tv_nsec } > initializers (common in practice even if not officially supported by the > standards) continue to work. Also, I think you should just use "long int" > for tv_nsec in the case where there is padding, as the standard-defined > type (and then the padding can be "int: 32", so avoiding any dependence on > whether compilers support non-int bit-fields). Certainly the choice of > types for tv_nsec and padding should not depend on the endianness (the > patch above is using __int32_t for the first field and __syscall_slong_t > for the second, regardless of which is tv_nsec and which is padding). Ok, I have fixed this up. > > There are namespace issues when changing installed headers. You can't use > macros such as BYTE_ORDER or BIG_ENDIAN because they aren't in the > standard-reserved namespaces. > > Unfortunately the definitions of __LITTLE_ENDIAN and __BIG_ENDIAN are in > (__BYTE_ORDER is in the architecture-specific ), > and while the non-reserved names therein are all conditional on > __USE_MISC, I don't think we really want to start exporting them from > every header that uses struct timespec. My inclination would be to have a > separate bits/ header that only defines the __LITTLE_ENDIAN / __BIG_ENDIAN > / __PDP_ENDIAN macros (or that defines those and includes the > architecture-specific header for __BYTE_ORDER), so that other headers can > test endianness without bringing in all the other __USE_MISC > endian-related macros from , but Zack might advise on how such > changes would fit into his header cleanups. I think I understand what you mean, but it seems strange. I'm going to send an RFC patch and we can discuss there. Alistair > > -- > Joseph S. Myers > joseph@codesourcery.com