In RHEL linux, using std::string variable assigned with ""(empty string value) is giving junk values

Question

In RHEL linux, using std::string variable assigned with ""(empty string value) is giving junk values

For example as in the below code

std::string str = "";

printf("%s",str.c_str());

I have one more code sample

int main()
{
string str = "";
printf("Str = %s\n" ,str.c_str());

string strTemp;
char * pcTRMP = new char [10];

//sprintf(pcTRMP,"%d" ,7);
sprintf((char*)strTemp.c_str() ,"%d" ,7);
printf("Str = %s\n" ,str.c_str());

sprintf((char*)strTemp.c_str() ,"%d" ,8);
printf("Str = %s\n" ,str.c_str());

return 0;
}

The result is Str = 7 Str = 8

where there is no assignment to str variable.

We checked in so many places in internet. I am hoping that someone can help me to resolve this issue.

The same code is working in older versions of RHEL Linux.

Answer 1

It is illegal to write into the pointer returned by std::string::c_str(). The documentation for std::string indicates explicitely that this results in undefined behavior. This pointer is originally of type const char *, specifically to express this limitation.

Regarding the results displayed by your program, I guess both strings point to the same empty string buffer (some internal const char empty[] = ""), so that a write to one results in changing the value of all empty strings.

If you really need to use sprintf instead of std::stringstream, you can use char vectors instead of strings:

std::vector<char> buf(10);
sprintf(buf.data(), "%d" ,7);
std::string result = buf.data();

Answer 2

You are messing with internal string pointers and, as a result, experiencing undefined behavior.

An std::string object is a C++ string object. You create such an object (str), then create a second one (strTemp), fetch a const char * from the second one - then you try to write integers into that char array. Of course, the compiler knows that this is wrong (const) and will complain:

invalid conversion from const char* to char*

So you forcefully ignore this error by casting the const away. Now, after forcefully ignoring an error, unexpected things happen.

This has nothing to do with the platform, at least in general. As it is undefined behavior, the symptoms may however differ depending on what platform you use. I'm thinking that both string objects (both being empty) share the same memory location (at least as long as they're identical) (on the platform that was used), so overwriting the memory behind the pointer returned by the second string also affects the first string object. If you assign different values to the strings, the sprintf() won't (depending on platform) affect the other string anymore (example) - of course that's still wrong.

Read up on C++/C (C++ objects, C pointers and the meaning of const) and specifically the documentation of std::string.

Edit:

The op appears to be focused on the platform, so I'll repeat the obvious here. Writing to (the const representation of) variable a (strTemp) and then expecting that data to be in variable b (str) is bogus. You are overwriting memory that you don't own and, concidentally, overwriting the internal memory of another variable (str). Under certain circumstances, that data just happens to end up in ANOTHER variable. This is just completely and utterly broken.
I really hope this is just a test program or something - and not a productive application.

And don't mix C/C++ like that. In C++, you can still create a char* (big enough) and use functions like sprintf() that expect such a C string to write to it - if there's a good reason. Otherwise, just write proper C++.

For example, if converting an int to a C++ string is your actual problem, here is an example:

#include <iostream>
#include <sstream>

//...
std::string str;
int number = 7;
ostringstream oss;
oss << number;
str = oss.str();

Some people write macros for that. There are other solutions as well (I think boost has something to offer, so does C++0x).