This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libiberty: hashtab allocation functions with an extra argument
> 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).
I meant, are there other parameters we might want to specify when
creating a hash table, but I guess we don't. Ok, post an updated
patch summarizing what we've discussed and let's see if it's a go.
> So my inclination is not to do them now unless someone needs them.
Ok.
> 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.
Neither is very good, but I have a slight preference for "ex" meaning
"extended" vs "arg" meaning "one of the callbacks takes an arg, and
here it is". It's more generic, which would make it more of a
candidate for a standard naming convention in the future.