Re: libiberty: hashtab allocation functions with an extra argument

[Daniel Jacobowitz <drow at mvista dot com>]

On Wed, Jan 15, 2003 at 02:30:55PM -0500, DJ Delorie wrote:
> 
> > Which you're not supposed to do, anyway, since the only allocation
> > function for these beasts returns an allocated pointer.  This doesn't
> > bother me much; I can not think of a correct use of the hash table
> > structure that would suffer from this problem.
> > 
> > That doesn't mean there isn't one, of course, but I can't think of one. 
> > It doesn't even affect the GCC garbage collector's walking functions,
> > since the extra fields would be unused.
> 
> > DJ, could you then tell me what your concerns are?  Your original response
> > was:
> > > 1. Changing the htab structure breaks backward compatibility.
> > 
> > which is not helpful in telling me what needs to be considered.
> 
> What you said above is pretty much it.  Is it even *possible* for an
> app to create its own copy of struct htab, such that it can be used
> with libiberty's functions?  If it is not possible for an app to do
> this, then you've addressed that particular BC issue.  But we should
> probably comment the header file noting that the structure may grow in
> the future, and applications must not rely on sizeof(struct htab) (or
> even compute the size of struct htab, for that matter).

It's possible, but exceedingly unlikely; you would have to duplicate
absolutely every line of htab_create_alloc in the application.  Nothing
returns a hash table by value, and htab_create_alloc allocates the hash
table.  Is that close enough?

Do you have any suggestions on better names for the alternate
allocation functions?  Neither of us liked my first attempt.

> To go even further, it would have been a good idea to have not defined
> the struct in a public header in the first place.  I can easily
> imagine apps that access the struct members directly, rather than
> using the access functions, so this is no longer a reasonable option.

Yes; in fact, GDB will have to do this to update the function pointers. 
The patch won't break applications which do so; the new members are
initialized to NULL and should be left that way for proper behavior, so
nothing is needed.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer