Clang not always detects return-stack-address error depending on context

Clang Frontend Using Clang
1

for the following functions:

const char *fstack() 
{
    char tab[100];

    return tab;
}

const char *fc_str()
{
    std::string s{"some text"};

    return s.c_str();
}

const char * f_stringstream()
{
    std::ostringstream s;

    s<<"another text";

    return s.str().c_str();
}

clang issues the warning [-Wreturn-stack-address], though the later 2 are not exactly on the stack but rather already deleted and on the heap.

What must I change in the following code or in my call to clang++ to get the same warning:

class C1 {
public:
std::string str;
};

const char* fun_class()
{
C1 c;
c.str=“class text”;
return c.str.c_str();
}

2

This isn’t a Static Analyzer issue. Could you please remove that tag?
-Wreturn-stack-address is implemented by a Sema diagnostic at around SemaInit.cpp.

BTW to have a warning for the missing cases, I think it would need to use some sort of lifetime analysis.
@Xazax-hun probably knows about this more.
I think this was the post about the lifetime annotations stuff.

3

There are some known false negatives for these warnings. Some of those might not be that hard to fix, but we might need to do some refactoring first. See the ticket Extend -Wdangling to handle assignments, not just initializations · Issue #63310 · llvm/llvm-project (github.com) for more details. Unfortunately, I do not have the bandwidth to work on this at the moment, but I am happy to review patches.

4

Doesn’t that depend on the implementation? libc++ has a short string optimisation, and I believe "some text" is short enough to fit on 64-bit architectures. Presumably for std::ostringstream it’s complaining about the temporary std::string created by str() potentially doing the same, though Clang may not be smart enough (and probably shouldn’t be in diagnostics?) to know that it’s not being hit and is instead returning heap-allocated memory (which of course is also being deleted, but that’s not what the warning is about, and that’s harder to prove things about).

5

Basically you are right, it’s of course implementation dependent
Then, returning a char* from an instance method after the class goes out of scope doesn’t seem to me to be a good practice and I consider it as quite risky. Of couse this would not apply if the “wrapper” function returned a class (string, .or other ) instead of a char*.

Plus in my case: I have to take over sources of about 1M loc where all warnings have been desactivated for a couple of years. So I’d prefer false positives.