Boost logo

Boost :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-02-04 05:19:55

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

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
How did you discover the "problem"?


Boost list run by bdawes at, gregod at, cpdaniel at, john at