From patchwork Thu Mar 21 04:09:41 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: DJ Delorie X-Patchwork-Id: 31927 Received: (qmail 34273 invoked by alias); 21 Mar 2019 04:09:46 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 34265 invoked by uid 89); 21 Mar 2019 04:09:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-14.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=Very X-HELO: mx1.redhat.com From: DJ Delorie To: "Carlos O'Donell" Cc: digitalfreak@lingonborough.com, libc-alpha@sourceware.org Subject: Re: bz1311954 - multilib variations in LC_COLLATE files, with fixes In-Reply-To: (codonell@redhat.com) Date: Thu, 21 Mar 2019 00:09:41 -0400 Message-ID: MIME-Version: 1.0 "Carlos O'Donell" writes: > Very minor. Thanks, I think this means that using 50% is the simplest > and easiest option then. Care to post patches that use 50% with >> ? iconv, localedef: avoid floating point rounding differences Two cases of "int * 1.4" may result in imprecise results, which in at least one case resulted in i686 and x86-64 producing different locale files. This replaced that floating point multiply with integer operations. While the hash table margin is increased from 40% to 50%, testing shows only 2% increase in overall size of the locale archive. https://bugzilla.redhat.com/show_bug.cgi?id=1311954 Reviewed-by: Carlos O'Donell diff --git a/iconv/iconvconfig.c b/iconv/iconvconfig.c index 0201450742..1e6066cdf0 100644 --- a/iconv/iconvconfig.c +++ b/iconv/iconvconfig.c @@ -1079,9 +1079,9 @@ write_output (void) /* Create the hashing table. We know how many strings we have. Creating a perfect hash table is not reasonable here. Therefore - we use open hashing and a table size which is the next prime 40% + we use open hashing and a table size which is the next prime 50% larger than the number of strings. */ - hash_size = next_prime (nnames * 1.4); + hash_size = next_prime (nnames + nnames >> 1); hash_table = (struct hash_entry *) xcalloc (hash_size, sizeof (struct hash_entry)); /* Fill the hash table. */ diff --git a/locale/programs/ld-collate.c b/locale/programs/ld-collate.c index bb4e2c539d..19b23c2453 100644 --- a/locale/programs/ld-collate.c +++ b/locale/programs/ld-collate.c @@ -2401,8 +2401,8 @@ collate_output (struct localedef_t *locale, const struct charmap_t *charmap, runp = runp->next; } - /* Add 40% and find the next prime number. */ - elem_size = next_prime (elem_size * 1.4); + /* Add 50% and find the next prime number. */ + elem_size = next_prime (elem_size + elem_size >> 1); /* Allocate the table. Each entry consists of two words: the hash value and an index in a secondary table which provides the index