[Asterisk-Dev] potentially nasty bugs in string pools usage

[Kevin P. Fleming]

Steve Murphy wrote:

> I've written code that uses a central pool for string storage. The pool
> area is a linked list of 1 meg memory blocks. Each string is registered
> via a hash table. If a new string to be entered is bigger than what will
> fit in the memory pool, a new block is allocated, and it is put there.
> No realloc, no changing of all the string addresses. And not that hard
> to implement.

That is part of the ultimate goal (as Luigi already mentioned I have 
been talking about this for a while). What you see now is just the first 
step towards that goal.

> In the application I did this for, I found a 10:1 ratio of commonality
> of strings entered. Thus, the savings on heap space of about 90%... your
> mileage may vary considerably, but in general, string pools like this
> are great, they reduce memory requirements, they speed things up by not
> calling malloc/free as much, they reduce the complexity of your
> interface, as far as copying a string vs. storing the address of the
> string type issues. 

And they also allow for very, very fast string comparisons, since you 
only need to compare the string pointers.