libiberty: hashtab allocation functions with an extra argument

[Daniel Jacobowitz]

On Wed, Jan 22, 2003 at 05:29:23PM -0500, DJ Delorie wrote:
> 
> > This trailed off without any further input.  Is my original approach
> > going to be OK?
> 
> I think the only unresolved issue is the naming of the extra functions
> and fields.  "foo_extra_arg" was just too ugly ;)

Yeah.  The second version I posted used foo_with_arg instead of foo_arg
which is really just as bad.

> In MS-Land, They use "Foo()" and "FooEx()" for the short and long
> versions of each function call.  I suppose we could use
> htab_create_ex() for the "extended" call.  Can we think of any other
> parameters we might like to pass to htab, so we don't have to do this
> again?

I have no idea.  Conceptually, yes.  There are six callbacks:
  hash
  compare-equal
  delete
  traverse
  alloc
  free

Callback has an opaque pointer already.  I added one to alloc/free. 
That leaves hash, compare-equal, and delete.  Do you think there's a
use for extra opaque pointers to those?  I've no idea.  Nor do I know
if they should come from an argument to the function which calls the
delete callback (like htab_trav) or when the htab is created (like
alloc/free).  So my inclination is not to do them now unless someone
needs them.  I can see delete needing an arena pointer someday although
I don't use it that way now.

I don't know if I like _ex, but if you prefer it to _arg I can
certainly do that.  We all seem to be short on better naming.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer