However, I still don't understand why it always chokes on the argv array.
If you mean the one we talked about: ``` gchar **argv = NULL;
#ifndef G_OS_WIN32 /* run within shell so we can use pipes */ argv = g_new0(gchar *, 4); argv[0] = g_strdup("/bin/sh"); argv[1] = g_strdup("-c"); argv[2] = g_strdup(cmd); argv[3] = NULL; #endif
g_strfreev(argv); ```
then I think the problem is that cppcheck doesn't find the allocation function because in
https://github.com/danmar/cppcheck/blob/4ce76d0b58d1c26f906ad71180f9577f05f3...
`g_new0()` isn't listed as an allocation function for `g_strfreev()`. It could be added to `gtk.cfg` but I'm not sure if such a change would be accepted upstream as not all `g_new0()` calls can be deallocated with `g_strfreev()` or do by deallocating the array in the code by a loop using `g_free()` which is kind of stupid.
This is all because of the `--library=gtk` command-line parameter which on the one hand fixes the macro problem, on the other hand the gtk.cfg config file doesn't seem to be universal enough to handle all possible cases (for instance, it also complains about `g_free(some_var)` where `some_var` is `NULL` which is legal for GTK). I'm wondering if it wouldn't be better to remove `--library=gtk` (and lose some of the allocations/deallocation checks) and handle the original problem of unknown macros in some other way (not sure how though).