On 5/30/19 3:12 AM, Fredrik Hederstierna wrote:
HiWhen reading the SEI CERT C Coding Standard rules, looking at "DCL30-C. Declare objects with appropriate storage durations" it seem like GCC does not warn in compile-time for some noncompliant examples. I know eg AddressSanitizer and several runtime running tools finds these bugs, but it would be convenient of GCC could do some basic static analysis already in compile-time to avoid bad code generation. Some static analysers finds these bugs, but not all, and GCC does not warn. Example from DCL30-C, not warned by GCC: /* NONCOMPLIANT EXAMPLE-1 */ #include <stdio.h> const char *p; void dont_do_this(void) { const char c_str[] = "This will change"; p = c_str; /* Dangerous */ } void innocuous(void) { printf("%s\n", p); } int main(void) { dont_do_this(); innocuous(); return 0; } /* NONCOMPLIANT EXAMPLE-2 */ void squirrel_away(char **ptr_param) { char local[10]; /* Initialize array */ *ptr_param = local; } void rodent(void) { char *ptr; squirrel_away(&ptr); /* ptr is live but invalid here */ }
Agreed. This (or a subset of the problem) is being tracked in PR 69433.
Question, where in GCC is the most appropriate place to implements such a checker? I know there are some warnings for return-local-addr, and null-pointer-dereference in some different parts, but this seems different? Can it be found be points-to analysis, or where is it best to put this warning if being implemented?
To me it seems close enough to -Wreturn-local-addr to be implemented in the same place, in gimple-ssa-isolate-paths.c. It's worth noting that besides warning, the pass also clears the returning address and isolates the path that returns the null in the CFG. As it happens, I recently submitted a modest enhancement to -Wreturn-local-addr to detect returning the addresses of VLAs and pointers obtained from alloca (PR 71924 and PR 90549). I'm working on extending the implementation to returning freed pointers (under a separate warning option). Besides the problems you mention, there is also a related request to diagnose dereferencing pointers to compound literals whose lifetime has ended (PR 89990), or more generally, those to any such local object. In the enhancement I submitted I chose not to use the alias oracle mainly because I didn't want to change the existing design. I'm not familiar enough with to tell with confidence if it can be used to obtain the same results. I.e., identify each instance of a local variable that a pointer may point to, rather than just answering the broad question: does this pointer point to any local variables? If it can, using it as Jeff suggests in his comments, would make sense. I don't think moving it out of gimple-ssa-isolate-paths.c is necessary (or even a good idea). Martin
Reference: https://wiki.sei.cmu.edu/confluence/display/c/DCL30-C.+Declare+objects+with+appropriate+storage+durations
