1) don't ignore stack-allocated variables, since they may hide
heap-allocated stuff (compound types)
2) check if there's a return between the variable declaration and its
initialization; if so, treat the variable as uninitialized
3) introduction of 2) increased the query runtime exponentially, so
introduce some optimizations to bring it back to some reasonable
values
This is a slightly modified version of the original
`cpp/uninitialized-local` CodeQL query which focuses only on variables
using the cleanup macros. Since this has proven to cause issues in the
past, let's panic on every uninitialized variable using any of the
cleanup macros (as long as they're written using the __cleanup__
attribute).
Some test results from a test I used when writing the query:
```
#define _cleanup_foo_ __attribute__((__cleanup__(foo)))
#define _cleanup_(x) __attribute__((__cleanup__(x)))
static inline void freep(void *p) {
*(void**)p = mfree(*(void**) p);
}
#define _cleanup_free_ _cleanup_(freep)
static inline void foo(char **p) {
if (*p)
*p = free(*p);
}
int main(void) {
__attribute__((__cleanup__(foo))) char *a;
char *b;
_cleanup_foo_ char *c;
char **d;
_cleanup_free_ char *e;
int r;
r = fun(&e);
if (r < 0)
return 1;
puts(a);
puts(b);
puts(c);
puts(*d);
puts(e);
return 0;
}
```
```
+| test.c:23:14:23:14 | e | The variable $@ may not be initialized here, but has a cleanup handler. | test.c:20:26:20:26 | e | e |
+| test.c:27:10:27:10 | a | The variable $@ may not be initialized here, but has a cleanup handler. | test.c:16:45:16:45 | a | a |
+| test.c:29:10:29:10 | c | The variable $@ may not be initialized here, but has a cleanup handler. | test.c:18:25:18:25 | c | c |
```
