This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Host endian independence
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Damien Zammit <damien at zamaudio dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 27 Aug 2019 15:54:41 +0000
- Subject: Re: Host endian independence
- Ironport-sdr: zHtu+ywCJ9E+CfOx0gMfY4QgLSDco1PBzufUk8VAYDBlW9TBYNQeV0u5JZ28VUEdAynJRrGEoa Lkzb9cOF1fXxCFnYKBzbK99BPRPuhuAdQMIZ3wvXMtQr52NP/4k1cpRZDRRxjh5f1PrACvvQzh jvLV1ATloBYVscjudo8IK1ttIBcssNpQbjR+vbjJvo3MWR+wcfR7Y293ScDXWSBrsleKtOkQKS HJ8t4Nl43EydZZeateTenm6ykv3NMi2jIs3e9swAbfVzl8ruOywdLvLMc+RcsZIHjrNS3h7893 usw=
- Ironport-sdr: GWaVNmwaQCVZRLXz+F9MCQN/KB5U8ViF6ZzSaDllEnZ0qlZ/QsCoooYXcU2/Q5eRUZ+HJEPUqk rjnFkS1IvyrqJBj42mbFTmKrvV9efGKZwM+viTFwQE9yGTbRiGYfxx2g8+kp1c6ZFbK3Vf8INJ dYf3V1eSjIMV1UYVT8/5k9Ebi5BmDzhMgzQCdXMhYYAbNd7GCxVlbHyKhW1y6ZWWoyC+83Xybs ZoplW7Qfegl4NNXT70m9Saf+YlP5Djl+jLFmo3IWkoM8GaF7jdfwtsJuwNRpQC9aFu179+71gD ljc=
- References: <18c8a820-b2c4-8ab2-58d1-8d8c851dbf01@zamaudio.com>
On Sat, 24 Aug 2019, Damien Zammit wrote:
> Please see attached patches for proof of concept, which remove
> dependence on BYTE_ORDER for two subfolders of glibc.
I don't think these changes are appropriate.
I think we should make more use of the *existing* byte-swap interfaces,
such as be32toh and be64toh in <endian.h>, rather than inventing new ones.
By using those interfaces, tzfile.c, for example, could lose some of its
existing endian checks (that would be a very small local change to the
implementations of the decode and decode64 functions, larger changes are
not needed and make the code less clean because the logical information
that certain data is stored in the files in big-endian format is best kept
local to the implementations of those two functions, rather than
hardcoding that information in lots of places with read_be32 and read_be64
names). (I'm not convinced that any changes in this area beyond very
minimal use of bswap_32 would improve the catgets code.)
--
Joseph S. Myers
joseph@codesourcery.com