提出garray是否会删除它？

Question

#include <stdio.h>
#include <stdbool.h>
#include <stdint.h>
#include <glib.h>

void transform_pointer_contents(GArray* const arr) {
    GArray* const tmp = g_array_new(true, true, sizeof(uint8_t));
    const uint8_t example_num = 5;
    g_array_append_val(tmp, example_num);

    *arr = *tmp

    // Why does this cause a double-free error?
    g_array_unref(tmp);
}

int main() {
    GArray* const arr = g_array_new(true, true, sizeof(uint8_t));
    transform_pointer_contents(arr);
    printf("Arr length is %d/n", arr->len);

    g_array_unref(arr);
}

问题

• 为什么在transform_pointer_contents的末尾的UNRE会导致双重免费？
• 我怀疑tmp的放证也以某种方式取消了它，如果是真的，它如何工作？我认为，C ++中类似的参考口类型可以通过覆盖取消运算符来起作用，但是C肯定无法正常工作？
• 我是否可以保证tmp在没有UNRE的情况下可以正确释放？

Answer 1

• 为什么在transform_pointer_contents的末尾的unref引起双重？

据推测，garray对象本身都不是双重释放的，而是临时对象数据的动态空间（tmp-＆gt; data）。那是因为

*arr = *tmp

执行浅副本。然后，当您减少临时的参考计数时，Glib会划分内部存储，arr-＆gt; data仍然指向。当arr后来不参考时，Glib试图再次对该数据进行处理。

请注意，还遵循最初分配给arr元素的数据存储。

最重要的是，GLIB不支持通过结构分配复制garray。而是使用GLIB数组函数来操纵Garray s。

• 我怀疑TMP的退化也没有[arr]，如果是这样，它如何工作？

解开TMP不解开arr。但是，鉴于您对arr的不支持的操作，解开tmp具有与> arr关联的元素存储（然后）的副作用。

我认为C ++中类似的参考口类型可以通过覆盖解释操作员来起作用，但是C肯定不起作用？

取消运算符（*）与观察到的不当行为无关，与GLIB的参考计数无关。不要将“参考”在此处的“参考”的不同用途混为一谈。在任何情况下，C都没有操作员超载。

问题在于，您不当导致一个garray的内部状态被与另一个的内部状态相反，因此当Glib释放一个响应一个参考数数时，它会降至零，以下另一个被损坏。首先，并不是说混蛋是一个干净的情况。

• 我是否可以保证没有UNREF？

可以正确释放TMP

不，您可以安全地假设tmp是 不是如果其参考计数未降低到零，则可以正确释放。因此，在丢失指针之前，请继续UNREF。如上所述，您需要更改的是结构分配。使用glib函数来操纵garray s。对于那些熟悉GLIB的人来说，可能会有可行的捷径，但是在这一点上，那不是您。