This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
locale files and int32_t alignment
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Wed, 4 Sep 2013 01:06:41 +0000
- Subject: locale files and int32_t alignment
- Authentication-results: sourceware.org; auth=none
Locale files output by localedef depend on the architecture (and so go in
/usr/lib/locale not /usr/share/locale) in two ways:
(a) Various values depend on endianness.
(b) The alignment of collation weights in the files depends on the
alignment of int32_t. I believe m68k is the only supported architecture
for which this is not 4 (it's 2 there).
I'm working on extracting and merging the changes from EGLIBC to make
localedef support generating locale files for another system. (I do not
propose to merge anything related to the separate build system for
cross-localedef.)
For (a), this involves appropriate command-line options --big-endian and
--little-endian. For (b), those changes involve another option
--uint32-align. But it's not so clear that this architecture dependence
makes sense. Most alignment in locale files uses (in localedef) hardcoded
sizeof (uint32_t) or 4 or 3 or similar expressions or constants (depending
on the exact alignment logic in each place), even if only the possibly
smaller alignment of int32_t is actually relevant. Perhaps we should
actually change the relevant code - in both localedef and libc - to use
sizeof instead of alignof, and so eliminate this architecture dependence?
(I believe it is always required that binary locale data is built with
localedef matching the glibc version in use - that there is no
compatibility requirement for the binary format to remain unchanged.)
--
Joseph S. Myers
joseph@codesourcery.com