This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: libiberty: hashtab allocation functions with an extra argument


> 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).

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.


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