Bug 82520 - Missing warning when stack addresses escape the current scope
Summary: Missing warning when stack addresses escape the current scope
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 7.1.1
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks: Wreturn-local-addr
  Show dependency treegraph
 
Reported: 2017-10-11 16:52 UTC by Adam Jackson
Modified: 2020-05-20 22:16 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-10-12 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Jackson 2017-10-11 16:52:57 UTC
Testcase:

-----
#include <malloc.h>

struct foo { void *v; };

struct foo *bar(void)
{
    int a[10];
    struct foo *ret = malloc(sizeof(struct foo));

    ret->v = &a;

    return ret;
}
-----

The address of 'a' is just somewhere on the stack. There might be rare cases where you'd want to do this, but usually this would be a bug.

Bug 63181 is perhaps a C++ variation of the same kind of problem, but clang doesn't warn for this one.
Comment 1 Andrew Pinski 2017-10-11 16:55:34 UTC
I think this is hard warning to happen.
Comment 2 Martin Sebor 2017-10-12 16:50:19 UTC
There are a number of classes of instances of this problem that GCC doesn't detect but arguably should and possibly could.  Examples include: pr69433, pr71924, and pr81811.   Detecting all of them may not be straightforward or even feasible but improving on the status quo certainly is possible.  This case does seem like one of the harder ones to catch.  Confirming with that caveat.
Comment 3 Eric Gallager 2019-11-21 09:26:56 UTC
(In reply to Martin Sebor from comment #2)
> There are a number of classes of instances of this problem that GCC doesn't
> detect but arguably should and possibly could.  Examples include: pr69433,
> pr71924, and pr81811.   Detecting all of them may not be straightforward or
> even feasible but improving on the status quo certainly is possible.  This
> case does seem like one of the harder ones to catch.  Confirming with that
> caveat.

The rest of these would all go under -Wreturn-local-addr, so I'm assuming that this one would, too.
Comment 4 David Malcolm 2019-12-10 17:35:20 UTC
FWIW the analyzer branch can warn about comment #0, but only if the value gets used, not simply that it escapes.

See e.g. the -Wanalyzer-use-of-pointer-in-stale-stack-frame warning within https://godbolt.org/z/PAtqhB

Probably ought to warn about it simply escaping.