> Would be good to explain there what the function does if the parameter
> is NULL.
Sure.
Ok. Please add the complete description to your patch.
> + if (pdf_hash_add (props_hash, "isHidden", (void *) is_hidden,NULL)
!=
> + PDF_OK)
> + {
> + return PDF_ERROR;
> + }
>
> Will the memory used by 'is_hidden' be released when the hash is
> destroyed being the last parameter NULL? As far as I understand in
> this case the dispose function defined for the hash will be applied.
Right, we have two choices,
1. we pass each function call the element dispose function.
I would prefer this one.
2. we give it at creation time, i.e. pdf_hash_create(). But now
that I see pdf_fsys_item_props_to_hash() doesn't create the hash
table, which should if we want to do this.
I would remove the possibility to use a table-wide memory disposal
function. Hashes tend to hold heterogeous values. That is certainly
our case where we will use hashes to implement the PDF dictionaries.
> newelt->key = key;
> ...
> gl_sortedlist_add ((gl_list_t)table.keys, key_compare, key);
>
> Is 'gl_sortedlist_add' making a copy of 'key'?
No, it is not. Also, remember that if the key is allocated from the
heap you could give pdf_hash_create() the key dispose function if
you need to.
The keys are always raw strings, isnt it? If it is the case I would
say to let the hash implementation to make a copy of it and manage its
memory.
