Missing nullptr check in implicit std::string construction in RemotedHandler::unwrap
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
While experimenting with a replacement for XMLTooling's TemplateEngine, I ran into the following:
While rendering the session error template, if TemplateEngine->run() does not write any output to the ostream it is given, RemotedHandler::unwrap will implicitly construct a std::string from a nullptr, causing a basic_string::_S_construct NULL not valid exception to get thrown.
In the situation described above, h["data"].string() returns a nullptr, causing the implicit std::string constructor to throw an exception.
Not a huge issue since you need to go out of your way to make template rendering fail in ways that can trigger this – just a small robustness improvement. I've checked other similar (i/o)stringstream constructor sites to check for similar issues, but all others I've found have a check in place.
Environment
None
Activity
Rod Widdowson January 29, 2018 at 5:54 PM
Cherry-picked in change
In case the project changed confused things. Also as
While experimenting with a replacement for XMLTooling's TemplateEngine, I ran into the following:
While rendering the session error template, if
TemplateEngine->run()does not write any output to the ostream it is given,RemotedHandler::unwrapwill implicitly construct a std::string from a nullptr, causing abasic_string::_S_construct NULL not validexception to get thrown.In the situation described above,
h["data"].string()returns a nullptr, causing the implicit std::string constructor to throw an exception.Not a huge issue since you need to go out of your way to make template rendering fail in ways that can trigger this – just a small robustness improvement. I've checked other similar (i/o)stringstream constructor sites to check for similar issues, but all others I've found have a check in place.