From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30413 invoked by alias); 17 Mar 2010 06:30:57 -0000 Received: (qmail 30383 invoked by uid 48); 17 Mar 2010 06:30:44 -0000 Date: Wed, 17 Mar 2010 06:30:00 -0000 From: "cgd at google dot com" To: glibc-bugs@sources.redhat.com Message-ID: <20100317063043.11394.cgd@google.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/11394] New: locale-archive differs between x86_64-linux and i686-linux due to unintentional hash difference X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2010-03/txt/msg00028.txt.bz2 locale-archive files generated on x86_64-linux and i686-linux differ unnecessarily, due a likely-unintentional hash difference. they're compatible with each other AFAICT, but they aren't identical when built fresh (and they easily could be). to repro: configure / build glibc for i686-linux and x86_64-linux. in each, install locale data & create a locale-archive file by doing: make localedata/install-locales 'SUPPORTED-LOCALES=en_US/ISO-8859-1 en_US.UTF-8/UTF-8' compare the locale-archive files. They're much the same, but the _NL_CTYPE_WIDTH tables are different. in particular, some of the early (high-level) 3level table entries have different order, and thus later data in the file also differs. However, each is usable/correct. the wcwidth_table 3level table is constructed by iterating charmap->char_table (a simple-hash). the iteration order depends order of entries in the table, which depends on the compute_hashval hash function (whose result is modded by the table size). the version of compute_hashval used for simple-hash returns unsigned long int, and the computed hash value differs between i686 and x86_64, so the 3level table gets populated in a different order, ... the hash table in this case doesn't make it to disk, so it's safe to tweak the return type. (the hashes that use compute_hashval and *do* make it to disk use uint32_t already.) while it's not strictly necessary to fix this, it's comforting to see identical results when building on 32-bit and 64-bit. will attach patch. -- Summary: locale-archive differs between x86_64-linux and i686- linux due to unintentional hash difference Product: glibc Version: 2.12 Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper at redhat dot com ReportedBy: cgd at google dot com CC: glibc-bugs at sources dot redhat dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux and i686-linux http://sourceware.org/bugzilla/show_bug.cgi?id=11394 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.