Why did it somewhat work in the past? Was it luck and poor checking or did it know about some of them? But indeed, it couldn't really know without a huge config file like yours.
Yes, cppcheck just check very clear bugs. It cannot check leaking through pointer sharing and so on, it doesn't know that util_* functions return allocated memory and just skip them to do less false-positives. But with config detailed enough it will be powerful tool.
Well, yeah, it could be misleading in existing code, but when you add it you know it will return; and it's quite nice when you're use to it. But that's right that it needs to be cared about.
Also, remember that g_return*_if_fail() is supposed to check for an *bug* in the caller code, so leaking in this case isn't IMO as much of a big deal as if it was in normal code path.
Actually such kind of bugs appear not only when you add the code but when you modify it. When you create a new function you carefully put all things at right place but next time you don't know who and how will modify this piece of code and this may cause a bug just because second look at this code it less "careful".
Just take a look and you will see that I was right: https://github.com/geany/geany/commit/8a817e694bafdf5106c672133902b5daef0fe8...
This is not "add new code bug", this is "modify code without checking around" bug. And checking g_*if_fail is really hard because you check return statements, you don't see them and committer just skipped this g_return_if_fail. Yes, defines are very evil:)
Maybe this is a bad example because there was a definitely-leak before this commit that transformed to possible-leak.
-- Best regards, Pavel Roschin aka RPG