This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/6] y2038: Introduce struct __timeval64 - new internal glibc type
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Arnd Bergmann <arnd at arndb dot de>, Lukasz Majewski <lukma at denx dot de>
- Cc: Alistair Francis <alistair23 at gmail dot com>, Joseph Myers <joseph at codesourcery dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, Samuel Thibault <samuel dot thibault at ens-lyon dot org>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, Florian Weimer <fweimer at redhat dot com>, Florian Weimer <fw at deneb dot enyo dot de>, Zack Weinberg <zackw at panix dot com>, Carlos O'Donell <carlos at redhat dot com>, Andreas Schwab <schwab at suse dot de>
- Date: Mon, 20 Jan 2020 13:46:33 -0300
- Subject: Re: [PATCH 3/6] y2038: Introduce struct __timeval64 - new internal glibc type
- References: <20200118072047.23071-1-lukma@denx.de> <20200118072047.23071-4-lukma@denx.de> <CAKmqyKPD=_3LZ+YBEn53ZuoPo0hq_vdAFTMHdmPwo5Q795Wekw@mail.gmail.com> <CAK8P3a0F0nrUjrWSzrfC3ZwJdC9keQhrORWJN2Uy78OEr-WFcA@mail.gmail.com> <20200119162212.111f29b2@jawa> <CAK8P3a1pTO8xnn9yEFK=NBstPyEU9i0SDPhUdnx1SgOC_gYeJg@mail.gmail.com> <20200119223038.07beb885@jawa> <20200120133407.7536463b@jawa> <CAK8P3a30Xcda0a61x2S-cdsCB8TXa9Njpa3QP_Mw5Ko2XyVOqg@mail.gmail.com>
On 20/01/2020 10:00, Arnd Bergmann wrote:
> On Mon, Jan 20, 2020 at 1:34 PM Lukasz Majewski <lukma@denx.de> wrote:
>>>> On Sun, Jan 19, 2020 at 4:22 PM Lukasz Majewski <lukma@denx.de>
>>>> wrote:
>>>>>> On Sat, Jan 18, 2020 at 11:48 PM Alistair Francis <alistair23@gmail.com> wrote:
>>>>
>>>> It would certainly help if this could be consistent across
>>>> architectures and libraries.
>>>
>>> Ok. Thanks for the input.
>>
>> Would it be OK to have:
>>
>> struct __timeval64
>> {
>> __time64_t tv_sec; /* Seconds */
>> __int64_t tv_usec; /* Microseconds */
>> };
>
> This would not work if you pass it into a kernel interface that expects
> a 32-bit suseconds_t on sparc64, but it should work as an internal
> type on all 32-bit architectures.
>
>> I would prefer to avoid changing typedef of suseconds_t as it may
>> affect struct timeval related operations.
>>
>> Using explicitly __int64_t for tv_usec seems better option, isn't it?
>
> Maybe a __suseconds64_t that happens to be 32-bit wide on sparc64?
If timeval64 kernel ABI expects tv_usec being a different type depending
of the architecture, it is an indication we should parametrize with a
__suseconds64_t.
As a side note, why tv_usec for timeval64 is a 64-bit value? Is it
related to some alignment constraint?