From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17420 invoked by alias); 5 May 2005 20:09:21 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 17378 invoked from network); 5 May 2005 20:09:18 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 5 May 2005 20:09:18 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j45K9IAi006117 for ; Thu, 5 May 2005 16:09:18 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j45K9HO25044; Thu, 5 May 2005 16:09:17 -0400 Received: from ballpeen.sfbay.redhat.com (ballpeen.sfbay.redhat.com [172.16.24.33]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j45K9Dth026458; Thu, 5 May 2005 16:09:13 -0400 Received: from ballpeen.sfbay.redhat.com (ballpeen.sfbay.redhat.com [127.0.0.1]) by ballpeen.sfbay.redhat.com (8.13.1/8.13.1) with ESMTP id j45K9DXL031975; Thu, 5 May 2005 13:09:13 -0700 Received: (from rth@localhost) by ballpeen.sfbay.redhat.com (8.13.1/8.13.1/Submit) id j45K99Jn031974; Thu, 5 May 2005 13:09:09 -0700 X-Authentication-Warning: ballpeen.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Thu, 05 May 2005 20:10:00 -0000 From: Richard Henderson To: Zack Weinberg Cc: Dave Korn , "'Nick Clifton'" , "'Alan Modra'" , "'Ben Elliston'" , binutils@sources.redhat.com Subject: Re: PATCH: use hashtab for pseudo op table Message-ID: <20050505200909.GA31889@redhat.com> References: <87fyx1cxfl.fsf@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fyx1cxfl.fsf@codesourcery.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2005-05/txt/msg00206.txt.bz2 On Thu, May 05, 2005 at 11:58:06AM -0700, Zack Weinberg wrote: > > So, perhaps a slight bit of work on the libiberty hashtab api, to > > offer a few interfaces that take a) NUL-terminated strings b) > > fixed-size structs and maybe even c) variable sized structs with > > parameters specifying an offset and size within the struct where the > > sizeof the struct can be found, would make you reconsider? > > I'd feel better about the interface, but I'd still be concerned about > the constant factors. And I want support for not-NUL-terminated > strings with length passed in separately, too. The libiberty hash table doesn't need any changes to support this. The comparison function is asymmetric. It's therefore possible to compare two completely different items. For instance: struct opcode { const char *name; // other stuff }; struct opcode_key { const char *start; size_t len; }; static int eq_opcode_name (const void *xelt, const void *xkey) { const struct opcode *elt = (const struct opcode *) xelt; const struct opcode_key *key = (const struct opcode_key *) xkey; if (strncmp (elt->name, key->start, key->len) == 0) return elt->name[key->len] == '\0'; else return 0; } const struct opcode * find_opcode (const char *start, size_t len) { struct opcode_key key; hashval_t hash; key.start = name; key.len = len; hash = // something like htab_hash_string, but with length return htab_find_with_hash (htab, &key, hash); } That said, I agree that the overhead of the indirection in the libiberty version will probably be noticable. r~