From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28135 invoked by alias); 6 May 2005 06:16:23 -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 28045 invoked from network); 6 May 2005 06:16:21 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 6 May 2005 06:16:21 -0000 Received: (qmail 22011 invoked from network); 6 May 2005 06:16:20 -0000 Received: from localhost (HELO taltos.codesourcery.com) (zack@127.0.0.1) by mail.codesourcery.com with SMTP; 6 May 2005 06:16:20 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Thu, 5 May 2005 23:16:19 -0700 To: Richard Henderson Cc: Dave Korn , "'Nick Clifton'" , "'Alan Modra'" , "'Ben Elliston'" , binutils@sources.redhat.com Subject: Re: PATCH: use hashtab for pseudo op table References: <87fyx1cxfl.fsf@codesourcery.com> <20050505200909.GA31889@redhat.com> From: Zack Weinberg Date: Fri, 06 May 2005 06:17:00 -0000 In-Reply-To: <20050505200909.GA31889@redhat.com> (Richard Henderson's message of "Thu, 5 May 2005 13:09:09 -0700") Message-ID: <87vf5wev64.fsf@codesourcery.com> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-05/txt/msg00226.txt.bz2 Richard Henderson writes: > 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. Won't horrible things happen when it tries to resize the table, if you do that? zw