This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] time: Create a endian_t.h headerfile
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 20 Sep 2019 16:51:38 +0000
- Subject: Re: [RFC] time: Create a endian_t.h headerfile
- Ironport-sdr: gCY8Bvn67/fd7Cmclp1MB7b6JuVMSXvIWFyEs+h3hWAYfxKUkt+bhxqiQfGzQ33qZ2YQVoj4EN 6zvRoUZAuyF6kkSYaUjwaVQXbkIRSZjiDz6QfdBsHL82YUDiOKQ0G8W4EeUDltJsoxW9UWAWw7 OHKxWZFyoeWT9E5PbnQPcz4PyVLWGM7Ic2qbhbttXejR8s5w9PhNeoFgO5BkydxpCkX3ypiXRs 9ralCtUJPjMjPWI4fLsa1CeI2I0KAcVqyidkd9VfmBLKsek1xelnqs4w88PScah4DCoou41Dkh 3Jo=
- Ironport-sdr: qDxbrmUSk3MOgzH84TJ5dvEXEScFNCOZx56Hw0yoTUOsTettouYyLvpVzjs8CXbGkZCMqC5xgz PrP6S0qhNmaCBHf9DWKp6dMRBbmRm9OmKgIIgBtIC6nr2ydHL1xDOj9wizE4CWfQVDiROrV1P4 401OHMu0/kWbiDQvJ/IKu1B8Y/oTV71I0DGsEGjueOayGbiN4HGUXySNr9zakFIv4qcD8nFUB6 FUfEcSc4tXXIgQ5/MDcaHGyLw1PqBESMkfsfkFkIgyRatQuMNVsdXfKsv7eAXtq9O+g4DEhkYG +E4=
- References: <firstname.lastname@example.org> <alpine.DEB.email@example.com> <CAKCAbMjm9AgEcQYA5TzFPo9OjgD=91N4Ti8o-GzFnL6qAwur4Q@mail.gmail.com>
On Fri, 20 Sep 2019, Zack Weinberg wrote:
> On Thu, Sep 19, 2019 at 7:34 PM Joseph Myers <firstname.lastname@example.org> wrote:
> > If anything, I think the cleanest naming would be to have <bits/endian.h>
> > be the architecture-independent header that defines these three macros and
> > includes <bits/endian-arch.h>, where the existing <bits/endian.h> headers
> > that define __BYTE_ORDER all get renamed to <bits/endian-arch.h>. So
> > you'd need to add bits/endian-arch.h to the "headers" setting in
> > string/Makefile.
> I believe I wrote that patch already, in fact, as part of my
> installed-headers cleanups series:
> https://sourceware.org/ml/libc-alpha/2019-06/msg00783.html Unlike a
> lot of those patches, it should be low-risk for application breakage
> and applicable independently.
Yes, that's the sort of thing I'd expect (and I had a comment on it in
<https://sourceware.org/ml/libc-alpha/2019-07/msg00561.html>). (This is
not a review. When retesting this patch it would be necessary to check if
any new includes of <endian.h> have been added to installed headers that
need updating as well.)
I should explicitly note that, while it's easy to think of possible
followup cleanups in this area, it's best *not* to combine such cleanups
with this patch in order to keep it of a reasonable size and complexity.
Joseph S. Myers