Exactly what makes a stringstream go bad?

[3hM2Nwbp]

I have the following:

std::string ipv4ToString(unsigned long int ip) // Guaranteed that 0 < ip < 0xFFFFFFFF
{
	std::stringstream ss;
	for(int i = 3; i  > -1; --i)
	{
		ss << ((ip >> (i * 8)) & 0xFF)  << '.';
	}
	if(ss) // <-- Is it possible for ss to be bad here? (apart from memory issues)
	{
		std::string ret = ss.str();
		return ret.substr(0, ret.size() - 1);
	}
	return "0.0.0.0";
}

It's nit-picking here, but I'm curious, as the documentation only says:

Documentation wrote:

If some error happens during the operation, the stream's badbit flag is set, and if the appropriate flag has been set with ios::exceptions, an exception is thrown.

I suppose that I can try to dive into the iostream source to find out if no one else has ever been curious about this, but I was desperately hoping to avoid that.

[Moschops]

badbit is (generally) set if the stream is corrupted, or data lost. For example, if you take a stream referring to a file, and position it to before the beginning of the file.

The standard states: "indicates a loss of integrity in an input or output sequence (such as an irrecoverable read error from a file".

[cnoeval]

Exactly what makes a stringstream go bad?

I blame the parents. Istream and Ostream never spend time with their children!

[kbw]

if(ss) // <-- Is it possible for ss to be bad here? (apart from memory issues) 

No, I don't think so. As cnoeval says, it's the rest of the family that has the problem.

[Moschops]

Cue a stream of puns :)

[1yR4jE8b]

i c wut you did thar