John Eddy wrote:
I noticed a potential hazard in exceptions.cpp of the thread library. The method:
const char* thread_exception::message() const
returns the c_str of a string with local scope. This is a problem at least in VC 7 .NET 2003. The error can be exposed by the following code. ...
This is true. This "bug" already has been reported (somewhere Dezember 2004): Ulrich Eckhardt wrote:
The code in question is this:
// boost/thread/exceptions.hpp class thread_exception { ... const char* message() const; }; // libs/thread/src/exceptions.cpp std::string system_message(int sys_err_code){..} const char* thread_exception::message() const { if (m_sys_err != 0) return system_message(m_sys_err).c_str(); return what(); }
If message() is called and m_sys_err is set, it will return a pointer to storage of a temporary, which is bad, as we all know.
I did some research on that, and I think this whole method can be removed completely because: - it is not decumented - it is not used - it never worked (probably, at least not with 1.32)
Further, one could then remove <string> from the includes in the header and some more includes in the sourcefile.
An alternative approach would be to change the returntype to std::string, of course, or (and I think that's an interesting alternative!) derive all those classes from std::runtime_error, which can hold a std::string natively.
Since the function does not yet belong to the documented interface, please don't use it. Use what() instead. Obviously to make message() work, it would need to have an additional string member, or as the above poster points out return a string by value. The second method (deriving from runtime_error) won't solve the problem in my opinion, since 1) We need two strings: one that is returned by what() and another returned by message() 2) We cannot access the string at the time message() is beeing called. We would need to do this at construction time, whether it will be used later or not. I would even prefer not to make message a member function at all. The exception simply should return the system error code, and a free message function beeing used to convert it to a meaningful string representation. Besides this, the whole issue is a mere theoretical one, since the various exceptions are not yet thrown with system codes attached. But perhaps I am wrong in this respect. How did you discover the "problem"? Roland