Re: [RFC PATCH] Hashtab iterators

[DJ Delorie <dj at redhat dot com>]

> There are a few hurdles because some functions must be moved to 
> hashtab.h, but they are easily done.

I'm not a big fan of functions in headers.  It's not as easy to debug
and contributes to bloating.

> In particular htab_size and htab_elements are now "static inlines",
> but they must be kept as "extern inlines" while compiling hashtab.c
> too.

*ick*

> I still have a problem however, and that's why this is an RFC: if I put 
> ANSI declarations in include/hashtab.h, libiberty compilation complains 
> because of -Wtraditional, while if I put old-style declarations, gcc 
> compilation complains because of -Wstrict-prototypes.  What to do? Would 
> it be ok to convert libiberty or hashtabs to ISO C and remove 
> -Wtraditional from there?

Yet another reason to avoid functions in headers.

If you want to convert libiberty/* to ANSI C (not include/* yet - one
step at a time) and you're willing to convert ALL OF IT at once, feel
free.  It's been on my project list for a while.  I just don't want a
partial conversion.

> +/* Return the current size of given hash table. */
> +
> +HTAB_STATIC_INLINE size_t
> +htab_size (htab)
> +     htab_t htab;
> +{
> +  return htab->size;
> +}
> +
> +/* Return the current number of elements in given hash table. */
> +
> +HTAB_STATIC_INLINE size_t
> +htab_elements (htab)
> +     htab_t htab;
> +{
> +  return htab->n_elements - htab->n_deleted;
> +}

Do you *really* need to expose these?  They're only used once per
loop, and if you're writing private functions anyway, they can just
peek at the data directly.


> +/* Attribute `always_inline' was valid as of gcc 3.0.  */

No, that's wrong.  It's not in 3.0 at all.