Re: [pdf-devel] Patch for FS#56 (second try)

[jemarch]

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