This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: bz1311954 - multilib variations in LC_COLLATE files, with fixes
- From: DJ Delorie <dj at redhat dot com>
- To: Rafal Luzynski <digitalfreak at lingonborough dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 20 Mar 2019 17:15:08 -0400
- Subject: Re: bz1311954 - multilib variations in LC_COLLATE files, with fixes
Rafal Luzynski <digitalfreak@lingonborough.com> writes:
> When this bug is fixed, will the locale archives be the same across
> all builds?
No, but only because big and little endian hosts will still build them
in their native endian-ness.
This fix just makes sure that, for example, i686 and x86-64 builds will
be the same. But i686 (little endian) will not be the same as s390 (big
endian).
> Well, the decimal fractions are known to be often infinite and never
> accurate in binary systems.
I thought about suggesting 37.5% so that it would happen to be (it's hex
0x0.6), but avoiding FP is still better.
>> /* Same value as before, but "/10" isn't exact */
>> elem_size = next_prime (elem_size * 14/10);
>
> What about:
>
> elem_size = next_prime (elem_size * 7/5);
I used 14/10 so that it's (hopefully) obvious it's a replacement for
1.4.
> If it does not have to be exactly 1.4 then what about:
>
> elem_size = next_prime (elem_size + elem_size / 2);
>
> which is 1.5?
That does grow the hash tables, and thus file size, by another 10%. I
tried to keep my examples close to the original values, because I don't
know what real-world effect a change in overhead would introduce.
>> Note this math also happens in ./iconv/iconvconfig.c:
>> hash_size = next_prime (nnames * 1.4);
>
> I guess this will need the same update.
Yup.