From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115129 invoked by alias); 25 Sep 2019 20:03:23 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 115116 invoked by uid 89); 25 Sep 2019 20:03:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=Director, director X-HELO: mail-out.m-online.net Date: Wed, 25 Sep 2019 20:03:00 -0000 From: Lukasz Majewski To: Joseph Myers , Florian Weimer Cc: Alistair Francis , Alistair Francis , Zack Weinberg , Arnd Bergmann , GNU C Library , Adhemerval Zanella , Florian Weimer , Carlos O'Donell , Stepan Golosunov Subject: Re: [PATCH v8 1/3] y2038: Introduce internal for glibc struct __timespec64 Message-ID: <20190925220315.64e6cdae@jawa> In-Reply-To: References: <20190918211603.8444-1-lukma@denx.de> <20190918211603.8444-2-lukma@denx.de> <20190923232109.735f898b@jawa> <20190925094540.14be491d@jawa> <877e5wtu7y.fsf@mid.deneb.enyo.de> <20190925153402.060a686c@jawa> <87lfucsddd.fsf@mid.deneb.enyo.de> <20190925163818.5e8a3a03@jawa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/PdxBMvNGZB8VCWBysycx/vO"; protocol="application/pgp-signature" X-SW-Source: 2019-09/txt/msg00433.txt.bz2 --Sig_/PdxBMvNGZB8VCWBysycx/vO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-length: 1075 Hi Joseph, Florian, > On Wed, 25 Sep 2019, Lukasz Majewski wrote: >=20 > > Let's wait for Joseph's opinion if we shall replace named padding > > struct members with unnamed bitfields (and drop potential support > > for fixing issues, which would require explicit clearing of padding > > before passing data to the kernel).=20=20=20 >=20 > I'm not particularly concerned with whether this patch uses named > padding, unnamed bit-field or 64-bit tv_nsec in the internal struct > __timespec64. (I don't think a named bit-field would make sense > there, however.) If we use an unnamed bit-field now we can readily > change it later to have a name if we decide to support clearing > padding for compat syscalls for kernels 5.1.0 to 5.1.4. >=20 Shall I assume that the consensus is to use unnamed bit-field to pad the tv_nsec? Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de --Sig_/PdxBMvNGZB8VCWBysycx/vO Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature Content-length: 488 -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl2LyAMACgkQAR8vZIA0 zr3qRAf/aOYhXDlvJkeIvarnV5XlToGHe0ehe6rt9aKVQdNiqrUT3hVZvVw/wbEe udATu7SEo3JMhhCQHaRSfR/CA0SyFMAZgq5DDu9f9DSpdoxyDoxMKtX+ExA1Gytp AN/jVAW8NYFvedMG9h1MkeM220I6tusMxNeQWCPshd5VTLpdVf8rpqibE0kYV0yZ omZW3wxO0Sa911kBeXnz8ixee+bkRllPMEq38Ha63fsKCCC6I10SZsZ66xMF8Ve/ Yd4dzydiWiBWbpeZw1IYyUF4yVn6c8XY/SPq1Gln4KVva3MF88/ruGvq5nR+YaUx V5nK2S0Uquc48VwBED0u8jOB0YRRRw== =V/N2 -----END PGP SIGNATURE----- --Sig_/PdxBMvNGZB8VCWBysycx/vO--