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/4ce76d0b58d1c26f906ad71180f9577f05f3642b/cfg/gtk.cfg#L702

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).

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.