This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v8 1/3] y2038: Introduce internal for glibc struct __timespec64
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Lukasz Majewski <lukma at denx dot de>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, Alistair Francis <alistair23 at gmail dot com>, Alistair Francis <alistair dot francis at wdc dot com>, Zack Weinberg <zackw at panix dot com>, Arnd Bergmann <arnd at arndb dot de>, GNU C Library <libc-alpha at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Florian Weimer <fweimer at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, Stepan Golosunov <stepan at golosunov dot pp dot ru>
- Date: Wed, 25 Sep 2019 16:28:58 +0000
- Subject: Re: [PATCH v8 1/3] y2038: Introduce internal for glibc struct __timespec64
- Ironport-sdr: fA1Sl6uk94vpUcqajrexEEaoqcEuJ7Y9Pl2NI0lHT3ARmlVcyeUyPODiIiC3zLGaNuZJ5zu/qn rAzc7B4+wuCVmirYsYABVouErPI8Ef2x0KiVtiVY9rSIgbC5FgrQIZ8ckhTLUSrZvhcsc6vnmR RV8TLm5keCWizz7Gsgmm5HgVzvImj/Hhu/BwqQZbag9LCw7TH/lXLjGmhwSexBI6NbuTL9VgDY r4VqTshws+55/pslTNj5wuE0P5t5cEDKXr8X6ObrSbGwBim2MHvtXJBLkwwvs1lRHsx1FTgwTE DhQ=
- Ironport-sdr: yTFJZpfjlr08O88QU+9Fsg129ZWo9OWQetdb7+RdJFj3EI2dJ5DkIHL96VDwtov46DPPF2VsVm Moz7oZfd5681eqzwbbbbIlUetoUWSZSmBbqhwMpMT9Wz9crF5W0EZR0Uzz5qnCnzpe3TrihUNQ JaHV2CaQdz1b6rEmR/1xca4hTZzmZ9PbVky399kNUgxLU/zO+BR+opw48KZowMJ3bHENNE50On v/wrhwh/we9/bK8tfd4TwY024xjH4vjfiraowOJ0XUEEZslrvWpE2/8i7B/DNXlivgicdv9zb0 WZQ=
- References: <20190918211603.8444-1-lukma@denx.de> <20190918211603.8444-2-lukma@denx.de> <alpine.DEB.2.21.1909192014250.11875@digraph.polyomino.org.uk> <20190923232109.735f898b@jawa> <alpine.DEB.2.21.1909250035540.14213@digraph.polyomino.org.uk> <20190925094540.14be491d@jawa> <877e5wtu7y.fsf@mid.deneb.enyo.de> <20190925153402.060a686c@jawa> <87lfucsddd.fsf@mid.deneb.enyo.de> <20190925163818.5e8a3a03@jawa>
On Wed, 25 Sep 2019, Lukasz Majewski wrote:
> 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).
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.
--
Joseph S. Myers
joseph@codesourcery.com