Why does this work: returning C string literal from std::string function and calling c_str()

Question

We recently had a lecture in college where our professor told us about different things to be careful about when programming in different languages. The following is an example in C++:

std::string myFunction()
{
    return "it's me!!";
}

int main(int argc, const char * argv[])
{
    const char* tempString = myFunction().c_str();

    char myNewString[100] = "Who is it?? - ";
    strcat(myNewString, tempString);
    printf("The string: %s", myNewString);

    return 0;
}

The idea why this would fail is that return "it's me!!" implicitly calls the std::string constructor with a char[]. This string gets returned from the function and the function c_str() returns a pointer to the data from the std::string.

As the string returned from the function is not referenced anywhere, it should be deallocated immediately. That was the theory.

However, letting this code run works without problems. Would be curious to hear what you think. Thanks!

Answer 1

Your analysis is correct. What you have is undefined behaviour. This means pretty much anything can happen. It seems in your case the memory used for the string, although de-allocated, still holds the original contents when you access it. This often happens because the OS does not clear out de-allocated memory. It just marks it as available for future use. This is not something the C++ language has to deal with: it is really an OS implementation detail. As far as C++ is concerned, the catch-all "undefined behaviour" applies.

Answer 2

I guess deallocation does not imply memory clean-up or zeroing. And obviously this could lead to a segfault in other circumstances.

Answer 3

As others have mentioned, according to the C++ standard this is undefined behavior.

The reason why this "works" is because the memory has been given back to the heap manager which holds on to it for later reuse. The memory has not been given back to the OS and thus still belongs to the process. That's why accessing freed memory does not cause a segmentation fault. The problem remains however that now two parts of your program (your code and the heap manager or new owner) are accessing memory that they think uniquely belongs to them. This will destroy things sooner or later.

Answer 4

I think that the reason is that the stack memory has not been rewriten, so it can get the original data. I created a test function and called it before the strcat.

std::string myFunction()
{
    return "it's me!!";
}


void test()
{
    std::string str = "this is my class";
    std::string hi = "hahahahahaha";

    return;
}

int main(int argc, const char * argv[])
{
    const char* tempString = myFunction().c_str();


    test();
    char myNewString[100] = "Who is it?? - ";
    strcat(myNewString, tempString);
    printf("The string: %s\n", myNewString);

    return 0;
}

And get the result:

The string: Who is it?? - hahahahahaha

This proved my idea.

Answer 5

The fact that the string is deallocated does not necessarily mean that the memory is no longer accessible. As long as you do nothing that could overwrite it, the memory is still usable.

Answer 6

As said above - it's unpredicted behaviour. It doesn't work for me (in Debug configuration). The std::string Destructor is called immediately after the assignment to the tempString - when the expression using the temporary string object finishes. Leaving the tempString to point on a released memory (that in your case still contains the "it's me!!" literals).

Answer 7

You cannot conclude there is no problems by getting your result by coincidence.

There are other means to detect 'problems' :

• Static analysis.
• Valgrind would catch the error, showing you both the offending action (trying to copy from freed zone -by strcat) and the deallocation which caused the freeing.

Invalid read of size 1

   at 0x40265BD: strcat (mc_replace_strmem.c:262)
   by 0x80A5BDB: main() (valgrind_sample_for_so.cpp:20)
   [...]
Address 0x5be236d is 13 bytes inside a block of size 55 free'd
   at 0x4024B46: operator delete(void*) (vg_replace_malloc.c:480)
   by 0x563E6BC: std::string::_Rep::_M_destroy(std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.13)
   by 0x80A5C18: main() (basic_string.h:236)
   [...]

• The one true way would be to prove the program correct. But it is really hard for procedural language, and C++ makes it harder.

Answer 8

Actually, string literals have static storage duration. They are packed inside the executable itself. They are not on the stack, nor dynamically allocated. In the usual case, it is correct that this would be pointing to invalid memory and be undefined behavior, however for strings, the memory is in static storage, so it will always be valid.

Answer 9

Unless I'm missing something, I think this is an issue of scope. myFunction() returns a std::string. The string object is not directly assigned to a variable. But it remains in scope until the end of main(). So, tempString will point to perfectly valid and available space in memory until the end of the main() code block, at which time tempString will also fall out of scope.