This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] time: Create a endian_t.h headerfile
On Fri, Sep 20, 2019 at 2:05 PM Alistair Francis <email@example.com> wrote:
> On Fri, Sep 20, 2019 at 9:51 AM Joseph Myers <firstname.lastname@example.org> wrote:
> > On Fri, 20 Sep 2019, Zack Weinberg wrote:
> > > On Thu, Sep 19, 2019 at 7:34 PM Joseph Myers <email@example.com> 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.
> That patch doesn't apply cleanly. What happened to this series? Should
> I wait for it to go in or should I look at manually applying this
It didn't turn out to be too bad to manually apply the patch.
I think I have something that is all working now. I haven't had a
chance to test it though.
> > 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
> > firstname.lastname@example.org