Regarding the issue of releasing memory in different modules about libimobiledevice

[mexmer]

if you look how function is written
https://github.com/libimobiledevice/libimobiledevice/blob/73b6fd183872096f20e6d1007429546a317a7cb1/src/afc.c#L513C13-L513C19
it internally call strdup ... eg. creates null terminated string duplicate, and returns pointer to it. since it's not structure there is no need for special handling, you just call free on returned pointer to string
https://en.cppreference.com/w/c/experimental/dynamic/strdup

[Jack-Leey]

if you look how function is written https://github.com/libimobiledevice/libimobiledevice/blob/73b6fd183872096f20e6d1007429546a317a7cb1/src/afc.c#L513C13-L513C19 it internally call strdup ... eg. creates null terminated string duplicate, and returns pointer to it. since it's not structure there is no need for special handling, you just call free on returned pointer to string https://en.cppreference.com/w/c/experimental/dynamic/strdup

I have tried this before, but it can cause the program to crash. Since I am using a dynamic link library (DLL) to call AFC_ Xxx ("libimobiledevice. ll" is also a dynamic DLL), and neither of them creates memory in the process stack area, so it does not follow the principle of "whoever creates memory should release it". In fact, the memory created by "afc_xxx" is in the module stack of "libimobile device. DLL", so I should use a "free" function in the "libimobile device. DLL" module to free up this memory.

[Jack-Leey]

Ah！！！！ I mistakenly closed the issue o(╥﹏╥)o

[mexmer]

if you look how function is written https://github.com/libimobiledevice/libimobiledevice/blob/73b6fd183872096f20e6d1007429546a317a7cb1/src/afc.c#L513C13-L513C19 it internally call strdup ... eg. creates null terminated string duplicate, and returns pointer to it. since it's not structure there is no need for special handling, you just call free on returned pointer to string https://en.cppreference.com/w/c/experimental/dynamic/strdup

I have tried this before, but it can cause the program to crash. Since I am using a dynamic link library (DLL) to call AFC_ Xxx ("libimobiledevice. ll" is also a dynamic DLL), and neither of them creates memory in the process stack area, so it does not follow the principle of "whoever creates memory should release it". In fact, the memory created by "afc_xxx" is in the module stack of "libimobile device. DLL", so I should use a "free" function in the "libimobile device. DLL" module to free up this memory.

are you sure, you releasing correct pointer? because it's created on global heap and following code works

char * keyval = nullptr;
if (afc_get_device_info_key(client, "requestedkey", &keyval) == AFC_E_SUCCESS && keyval) {
  printf("%s", keyval);
  free(keyval);
}

[nikias]

@mexmer you have to understand that Windows is really weird in all regards. So @Jack-Leey is right asking for a library free function. libplist already has one for the same reason.

[mexmer]

@nikias i program under windows in c++ over 15 years. but now when i think of it, you both are right, should not have written answer late night.

for me the code works, because i use static compiled libimobile, so free is done in same process as allocation.

alltough there is a thing. if you use MSVC on windows, strdup memory allocation is internally implemented with HeapAlloc. if you will compile with gcc, or any other compiler, it will most likely use malloc and that's where problem lies. so to be safe, it's better to release pointer from dll as @Jack-Leey asks.

in win32api is quite common either use deallocate function (supplied by dll), or more common way is simply pass preallocated buffer from outside, and throw error if it's not big enough, or truncate data if possible.