Hey, On Sat, 2015-02-07 at 22:43 +0100, Sergio Mariotti wrote: *snip*
* does the (transfer full) annotation applied to an array type mean that it's both safe and required to free array member elements before freeing the array itsef? i.e. if a clear function is set must there instead be a (transfer container) annotation?
Interesting question. After a bit of poking around, I think it’s currently ambiguous. The gimarshallingetests.c file is never run — it’s only scanned to check that the scanner works, so the code in it can’t be considered 100% reliable. It would be good to have comment from someone who knows the original intent behind (transfer full), plus some input from bindings authors since there might be a convention established already. I couldn’t infer one from the pygobject or Vala source. If there is no convention, I suggest it makes more sense to have the caller only ever call g_array_unref(), g_ptr_array_unref(), g_hash_table_unref(), and never explicitly free the elements. For (transfer full), the callee should be responsible for setting the clear/free function for elements. For (transfer container), the callee should be responsible for *not* setting such a function (or for adding the elements to a newly allocated container with no free function set, or similar). That would follow the trend of encouraging use of clear/free functions in containers, and leave the burden of memory management up to the callee rather than the caller, allowing it to change its internals in future if it wants. (For example, to switch from a GPtrArray<owned string> to a GPtrArray<unowned string> by simply removing the free func without needing to modify the caller.) Philip
Attachment:
signature.asc
Description: This is a digitally signed message part