Hello Jean-Michel, Thanks for your bug report and your patch! What about just using __attribute__((__packed__)) on the structure? That should give the same alignments on all architectures. Then if there are some type size difference, we can use uintXX_t types to enforce the correct size on all arch.
Be aware that it's preferred - if possible for you - to send patches in the e-mail body compared to sending them as attachment. Regards, Yann December 1, 2025 at 12:29 PM, "Jean-Michel Hautbois" <[email protected] mailto:[email protected]?to=%22Jean-Michel%20Hautbois%22%20%3Cjeanmichel.hautbois%40yoseli.org%3E > wrote: > > Hi, > > I'm looking for comments on this patch that fixes a locale data corruption > issue when cross-compiling from x86_64 host to m68k (ColdFire) target. > > gen_ldc runs on the host and computes structure member offsets using > offsetof(). These offsets are baked into locale_data.c as integer literals. > > When cross-compiling for a target with different alignment requirements > and pointer sizes, the structure layout differs: > > x86_64 host: int32_t alignment = 4 bytes, size_t = 8 bytes > m68k target: int32_t alignment = 2 bytes, size_t = 4 bytes > > This causes locale data corruption - for example, decimal_point pointing > to wrong memory (showing 0x03 instead of '.'). > > After a few tests and manips, I have the following patch which: > - Uses uint32_t instead of size_t for lc_common_tbl_offsets > - Uses #pragma pack(2) to force consistent structure layout > > I need comments, as it certainly is not the proper fix :-). The #pragma > pack(2) is m68k-specific; other 32-bit targets with 4-byte alignment > (ARM, MIPS, etc.) may not need it. And also, using uint32_t assumes > 32-bit target; 64-bit targets would need size_t. > > I'm open to suggestions on how to make this more generic ! > > Thanks, > JM > > _______________________________________________ > devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
