Hi,
Since now we allocate memory for the key, we should provide the
> `key_destroy_func` when calling g_hash_table_new_full(), otherwise
> this new memory will not be de-allocated.
>
Ack
IIUC it can be null, only if `uuid` was null since glib memory
> API usually terminates the application if me
On Thu, Nov 07, 2024 at 01:52:01PM +0100, Dorinda Bassey wrote:
In `virtio_add_resource` function, the UUID used as a key for
`g_hash_table_insert` was temporary, which could lead to
invalid lookups when accessed later. This patch ensures that
the UUID remains valid by duplicating it into a newly
On Thu, Nov 7, 2024 at 2:43 PM Stefano Garzarella wrote:
>
> On Thu, Nov 07, 2024 at 01:52:01PM +0100, Dorinda Bassey wrote:
> >In `virtio_add_resource` function, the UUID used as a key for
> >`g_hash_table_insert` was temporary, which could lead to
> >invalid lookups when accessed later. This pat
On Thu, Nov 7, 2024 at 1:52 PM Dorinda Bassey wrote:
>
> In `virtio_add_resource` function, the UUID used as a key for
> `g_hash_table_insert` was temporary, which could lead to
> invalid lookups when accessed later. This patch ensures that
> the UUID remains valid by duplicating it into a newly a
In `virtio_add_resource` function, the UUID used as a key for
`g_hash_table_insert` was temporary, which could lead to
invalid lookups when accessed later. This patch ensures that
the UUID remains valid by duplicating it into a newly allocated
memory space (persistent_uuid). The value is then inser
