From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100922 invoked by alias); 25 Sep 2019 14:38:32 -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 100908 invoked by uid 89); 25 Sep 2019 14:38:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=practices, timespec64, consensus, sk:cross-a X-HELO: mail-out.m-online.net Date: Wed, 25 Sep 2019 14:38:00 -0000 From: Lukasz Majewski To: Florian Weimer , Joseph Myers 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: <20190925163818.5e8a3a03@jawa> In-Reply-To: <87lfucsddd.fsf@mid.deneb.enyo.de> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/Q5d_BmUsCN+bWMjo327XI9p"; protocol="application/pgp-signature" X-SW-Source: 2019-09/txt/msg00412.txt.bz2 --Sig_/Q5d_BmUsCN+bWMjo327XI9p Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-length: 2027 Hi Florian, > * Lukasz Majewski: >=20 > >> Regarding the actual patch, I don't understand why tv_pad isn't an > >> *anonymous* bit field.=20=20=20 > > > > The reason for this is that we may need to clear this padding if we > > plan to fix some issues - for example in kernel 5.1.0 - 5.1.4 there > > is a bug for x32 which may require explicit clearing the padding.=20=20 >=20 > I think we cannot support those kernels with reasonable effort. So > cross-architecture source compatibility with existing practices is > more important. I see your point. >=20 > Furthermore, I think the consensus for the public struct timespec64 is > that it should use an unnamed bitfield because of the prevalence of > incorrect (according to POSIX) initializers. Yes. Correct. >=20 > >> This seems to introduce unnecessary variance > >> between architectures and is incompatible with how glibc itself > >> uses struct timespec.=20=20=20 > > > > The v3 of this patch had this field defined as anonymous padding. > > However, there was strong objection for such approach [1].=20=20 >=20 > > Links: > > [1] - https://sourceware.org/ml/libc-alpha/2019-05/msg00151.html=20=20 >=20 > The patch has a named bitfield: >=20 > + int tv_pad: 32; /* Padding named for checking/setting */ >=20 Ach. Yes indeed - there was a _named_ bitfield in the patch.=20 > As far as I can see, the discussion was about what was actually in the > patch, and not an unnamed bitfield. Yes, you seems to be right. Andreas objection was about the bitfield usage. 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 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_/Q5d_BmUsCN+bWMjo327XI9p Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature Content-length: 488 -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl2Le9oACgkQAR8vZIA0 zr3SnAf7BZ9vGKD1zvjggqRO/PUKs3nyYCP7niHw0E2ErK72IH2Dr48Fx5rLZoby ESuRbIHLfR2K7N7J08TJIA2X4QXJrGXvxYwTACjLQy7iYtsU45aYAntjU4oeIKhK RKRt+/YS+tj+v8f7wYXBzFJ1huZ42LS65WyaqBGLuRRHghRnwYbZclmN+vlHQA91 kh8vxqLU1Ye+LfHH03f5pe/lA9pGg76etV/7bnRbHm0/3bM3A6jhTS1x0EK0iY2g 3p6xmK2PuF9XFbu88DHFhqMOITSozColHP5FXOnqyZ+Lyoy4dCvn7bHiH31lndY3 BhjpPSAZOVDsX+TMLyX3e36PjbmNDg== =AKRu -----END PGP SIGNATURE----- --Sig_/Q5d_BmUsCN+bWMjo327XI9p--