[Bug c/52923] New: Warn if making external references to local stack memory

[Bug c/52923] New: Warn if making external references to local stack memory

[fredrik.hederstierna@securitas-direct.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923

             Bug #: 52923
           Summary: Warn if making external references to local stack
                    memory
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: fredrik.hederstierna@securitas-direct.com


Created attachment 27123
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27123
Example code with functions returning with stack memory refs bugs.

GCC does warn if returning a pointer to a local variable (stack memory).
But there are alot of more cases where GCC could possibly warn,
eg. when references are made to local variables or stack memory.

See this attached example code.
GCC warns for first case, but not the others.
I think all cases can be considered program bugs,
and could trigger a compiler warning I think.

I've found out that the present warning is done in "c-typeck.c",
is this the right place to but additional warnings of this kind too?

Thanks & Best Regards
Fredrik Hederstierna

The example code file was compiled with "-O2 -W -Wall -Wextra"
for enabling as many warnings as possible.

[Bug c/52923] Warn if making external references to local stack memory

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-04-10 07:59:40 UTC ---
These all need to have some kind of flow analysis going on (the return one is
the only one which does not which is why we warn already).

[Bug c/52923] Warn if making external references to local stack memory

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-10 08:03:13 UTC ---
See also PR 49974 requesting the same thing for C++

and PR 51270 and PR 44859 are similar but for temporaries

[Bug c/52923] Warn if making external references to local stack memory

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-04-10
     Ever Confirmed|0                           |1

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-10 12:33:38 UTC ---
We lack a must points-to analysis pass.  But it's questionable to warn for

void* test_alloc_struct_ptr_to_stack_mem(void)
{
  int a[100];
  struct test* t = (struct test*)malloc(sizeof(struct test));
  // GIVE WARNING?
  // "function returns with reference to local variable?"
  t->ptr = a;
  return t;
}

as you have no idea whether t is actually dereferenced in the caller.

void* test_alloc_struct_on_stack_mem(void)
{
  struct test* t = (struct test*)alloca(sizeof(struct test));
  t->ptr = NULL;
  // GIVE WARNING?
  // "function returns allocation from stack memory?"
  return t;
}

for this I'd say yes, warn.  Similar for returning a pointer that was free()d.

[Bug c/52923] Warn if making external references to local stack memory

[fredrik.hederstierna@securitas-direct.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52923

--- Comment #4 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> 2012-04-10 12:52:36 UTC ---
Maybe it have advantages to have a "pointer-deref" analysis pass rather than a
"point-to" analysis pass. Then GCC could warn only if the pointer is being
dereferenced for real, this to avoid false positives. But in case of shared
library-code etc, I guess we never know what users/callers will do with the
pointer...

Could there possibly be a connection to the work I think maybe Jeff Law and
others maybe are doing will null-deref checking pass? I guess they already do
some flow analysis and then checking for null-deref rather than
'dangeling-mem-deref' in this case (eg. stack local mem, or free()d-mem).

(I think this is done in PR16351.)

I also seen the __attribute__((nonnull)) with -Wnonnull, could it be possible
perhaps to have some __attribute__((nonlocal)) or similar when declaring
pointer?
/Fredrik