Question about GCC not warning for some noncompliant SEI CERT C code examples

[Martin Sebor]

On 5/30/19 3:12 AM, Fredrik Hederstierna wrote:
> Hi
> 
> When 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
>