This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: use hashtab for pseudo op table


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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]