Re: [boost] Bug in Boost.Thread?

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 
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