This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 2/5] y2038: Introduce struct __timeval64 - new internal glibc type
- From: Alistair Francis <alistair23 at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Lukasz Majewski <lukma at denx dot de>, Paul Eggert <eggert at cs dot ucla dot edu>, Adhemerval Zanella <adhemerval dot zanella at linaro 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, 27 Jan 2020 17:32:01 -0800
- Subject: Re: [PATCH v2 2/5] y2038: Introduce struct __timeval64 - new internal glibc type
- References: <20200126145258.32643-1-lukma@denx.de> <20200126145258.32643-2-lukma@denx.de> <CAKmqyKMXxvur5C0xrXCQRr2aAoNysQNBL5c8BMzXtZAKgxMEiQ@mail.gmail.com> <alpine.DEB.2.21.2001280042410.28987@digraph.polyomino.org.uk>
On Mon, Jan 27, 2020 at 4:47 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Tue, 28 Jan 2020, Alistair Francis wrote:
>
> > Can this be moved to time/bits/types/struct_timeval.h?
>
> That's an installed header. Internal types don't belong in installed
> headers unless unavoidable. Note that the __USE_TIME_BITS64 conditionals
> we eventually get in installed headers will (for example) change the
> contents of "struct timeval" depending on __USE_TIME_BITS64, rather than
> adding a new type with an internal name.
>
> > The reason is that we need it in include/bits/types/struct_rusage.h
> > and including time.h results in exposed symbols (from memory I see
> > glibc test failures when trying to do this).
>
> include/bits/types/struct_rusage.h is a *wrapper* round an installed
> header. Although such wrappers can contain internal declarations under a
> !_ISOMAC condition, it's best not to in this case because of the rule that
> including <bits/types/foo.h> should always get a definition of the type
> foo and nothing else beyond foo's dependencies, and breaking that rule
> would be confusing.
How should I add a __rusage64 type then? Right now I have modified
include/bits/types/struct_rusage.h to include the header twice with
different definitions based on macros.
>
> > The other problem is that we need __timeval64 in time/sys/time.h for
> > __getitimer64() and __setitimer64() and include/time.h isn't included
> > in there.
>
> But time/sys/time.h is an installed header. So it shouldn't get internal
> types either. __getitimer64 and __setitimer64 are not public interfaces
> (nor, as APIs, should they ever be, though eventually __USE_TIME_BITS64
> may cause redirection to such names as ABIs).
>From memory I was seeing compiler failures, as something doesn't
include time.h. I can look into this more though.
Alistair
>
> The installed header changes for _TIME_BITS=64 support aren't until all
> the internal pieces are ready. Until then, to a first approximation, you
> should only be changing *internal, non-installed* headers and
> implementation files, not installed headers.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com