Memory leak in `uci_lookup_section_ref()` function about edgesec

[mereacre]

@aloisklink I had a look at the function and it seems that it has one memory leak and possibility to free a memory region which is not supposed to be freed by the uwrt_lookup_package.

Memory leek :)

edgesec/src/utils/uci_wrt.c

Line 76 in a3bcd1b

if ((ti = os_calloc(1, sizeof(struct uci_type_list))) == NULL) {

- when it allocates a struct uci_type_list causing a memory leak

Freeing a pointer which is not supposed to be freed:

edgesec/src/utils/uci_wrt.c

Line 110 in a3bcd1b

ret = s->e.name;

The pointer is freed here:

edgesec/src/utils/uci_wrt.c

Line 236 in a3bcd1b

if (typestr != NULL) {

Solution memory leak:

Add a sys_free(ti) here

edgesec/src/utils/uci_wrt.c

Line 107 in a3bcd1b

and remove the below line (no idea why is the purpose of it)

edgesec/src/utils/uci_wrt.c

Line 113 in a3bcd1b

ti->idx++;

Solution for freeing the wrong pointer:

Replace the below line with

edgesec/src/utils/uci_wrt.c

Line 110 in a3bcd1b

ret = s->e.name;

ret = sys_strdup(s->e.name)

[aloisklink]

Memory leek :)

🥬🧅 😆

(Unfortunately, the Unicode® consortium rejected all three proposals for a leek emoji, so instead I have to combine 🥬 and 🧅 😭)

Solution memory leak

Your solution sounds good! Feel free to make a PR (although use os_free or just plain free() instead of sys_free())!

Freeing a pointer which is not supposed to be freed:

Actually, I don't think this is an issue. In the function uci_lookup_section_ref(), you don't need to free() the return value. Instead, you need to free(*typestr);

E.g. this is how I believe the function needs to be used:

char *malloced_memory = NULL;
const char *return_value = uci_lookup_section_ref(A, B, &malloced_memory);
free(malloced_memory); // only allocated if need be

I can make a PR that documents this behaviour.

[mereacre]

Feel free to make PR.

[aloisklink]

and remove the below line (no idea why is the purpose of it)

edgesec/src/utils/uci_wrt.c

Line 113 in a3bcd1b

ti->idx++;

I've figured out the purpose of it (see PR #485 for a fix!)

Basically, if you call this function again with a different section that has the same type as a previous UCI section, it should print @section_name[0], @section_name[1], @section_name[2], ...:

But since we weren't saving the increment, it was always doing @section_name[0], @section_name[0], @section_name[0] (0 each time!).