Large stack use-Coverity issue

[asaifudeen]

I have used local std::stringstream in my funtion which stores huge data in it. When i run Coverity Desktop analysis, i'm getting "Large stack use-Coverity issue". Can anyone suggest an alternative efficient datastructure, which can take the same amount of data

[jonnin]

the internet claims that by trying this:

std::string str;
str.reserve(50);
std::stringstream sstr(str);

you may be able to force the stringstream to migrate to the heap instead.

I have not tried it.

another suggestion is strstream which is the former version but still works.

[helios]

I doubt std::stringstream is the problem. Is it possible it might be detecting an infinite recursion?

[dhayden]

It's unlikely that a local stringstream is causing a large stack. Look for a large local array (or class with a large array member). To fix this, use a vector<> instead of an array.

[asaifudeen]

Thanks to all, for the reply.
I tried
std::string str;
str.reserve(50);
std::stringstream sstr(str);

But it didn't work.

There's no infinite recursion.

I'll try with vector with once.

[jonnin]

you can directly change an array for a pointer if you delete it when done.
vector would work too, but might be more work, be sure to reserve it for your expected data size or it will suicide reallocating when you go to use it.

a large stack is harmless unless you actually have a program crash due to out of stack space. Also, most compilers let you increase the stack size, go ahead and bump it up. This may be a "non issue". If it isn't broke...

[dhayden]

Can you post the function that Coverity is complaining about?

[AbstractionAnon]

Both std::string and std::stringstream have relatively small stack footprints.

If a string is less than 16* bytes, the data will be stored directly in the string object.
If a string is >= 16* bytes, space for the data is allocated from the heap.
* This is implementation defined, but 16 bytes is common.

Since stringstream uses a std::string for storage, the above rules apply. Therefore, if you are outputting more than 16 bytes to a stringstream, the storage for that data will on the heap.

[jonnin]

I saw this also, but I couldn't find a straight answer on what happens if you start with 1 byte on the stack and push it past (16, 64, whatever limit) ... does it grow on the stack, or move to the heap behind the scenes (very inefficient for handling many small strings on the edge of the limit)? That is where the workaround code above came into play, trying to reserve it on the heap to begin with...

I wonder if '16' is 'machine word size' or just arbitrary.

[helios]

if you start with 1 byte on the stack and push it past (16, 64, whatever limit) ... does it grow on the stack

That would be impossible. Suppose you had allocated another object on the stack, on top of the std::stringstream.
1. What to do with this object? Does it get destructed and reconstructed elsewhere? What if there's other objects? In what order should they get moved?
2. How could the std::stringstream know about this object?

[jonnin]

That is what I was thinking also but if that is true it seems like putting it on the stack at all is a mistake and that the data piece at least should be a pointer. It sounds like the container is doing something it should not.

[dhayden]

It means that the string has a fixed length 16-byte buffer for storing short strings. When the string exceeds that size, the class copies the data to the heap. The fixed length buffer doesn't go away, it just isn't used anymore.

For any object, the amount of space on the stack is sizeof(object).

Coming back to the original question, if you post the code we can probably help.