[pacman-dev] alpm_add_pkg() stealing ownership of allocated objects
Hello, While doing experiments, I discovered that alpm_add_pkg() seemingly stole the ownership of a pmpkg_t previously allocated by alpm_pkg_load(). I am a bit confused here. I think the documentation can definitely be improved here: can someone confirm the following statements? * a pmpkg_t* returned by alpm_pkg_load() must be freed by the caller unless otherwise specified * if alpm_add_pkg() is called on that package, then the caller MUST NOT free the pmpkg_t afterwards. Am I right? Are there any other functions with similar behaviour to alpm_add_pkg() ? Regards, Rémy.
Rémy Oudompheng wrote:
Hello,
While doing experiments, I discovered that alpm_add_pkg() seemingly stole the ownership of a pmpkg_t previously allocated by alpm_pkg_load(). I am a bit confused here. I think the documentation can definitely be improved here: can someone confirm the following statements?
* a pmpkg_t* returned by alpm_pkg_load() must be freed by the caller unless otherwise specified * if alpm_add_pkg() is called on that package, then the caller MUST NOT free the pmpkg_t afterwards.
Am I right? Are there any other functions with similar behaviour to alpm_add_pkg() ?
I cannot look now, but you might be right, and this definitely needs careful reviewing. Can you open a ticket ? I wonder if add_pkg should handle pmpkg from files differently and duplicate these before adding them to the transaction. This would be less confusing to the frontend, which would always need to free a pmpkg coming from pkg_load.
On 2011/4/12 Xavier <chantry.xavier@gmail.com> wrote:
I cannot look now, but you might be right, and this definitely needs careful reviewing. Can you open a ticket ?
I wonder if add_pkg should handle pmpkg from files differently and duplicate these before adding them to the transaction. This would be less confusing to the frontend, which would always need to free a pmpkg coming from pkg_load.
I opened FS#23731 about this issue. I also opened FS#23732 about a very unconvenient behaviour with empty transactions. Rémy.
participants (2)
-
Rémy Oudompheng
-
Xavier