
Short notes: * thread_exception::message() is broken beyond repair, as it returns a pointer to local storage (via std::string::c_str()) * any program using it is broken, too. * it is unused by boost itself(!) which is why it can be removed * it is the only reason why a helper-function 'system_message()' is needed, which can then be removed, too. * system_message() is the only reason several headers and a hack for strerror() were needed, which can then also be removed. * system_message() requires a char-based API on win32, which is not available under MS Windows CE, strerror() is also not available there, making two more reasons to remove it. cheers Uli

Ulrich Eckhardt wrote:
Short notes:
* thread_exception::message() is broken beyond repair, as it returns a pointer to local storage (via std::string::c_str()) * any program using it is broken, too. * it is unused by boost itself(!) which is why it can be removed * it is the only reason why a helper-function 'system_message()' is needed, which can then be removed, too. * system_message() is the only reason several headers and a hack for strerror() were needed, which can then also be removed. * system_message() requires a char-based API on win32, which is not available under MS Windows CE, strerror() is also not available there, making two more reasons to remove it.
cheers
OK, thanks. I'll attend to it (and a couple of other fairly recent bug/patch reports) when I get a chance. I'm still catching with a backlog of work caused by my machine dying, and I haven't gotten my Boost CVS access set up yet either. Mike

Ulrich Eckhardt <uli@doommachine.dyndns.org> wrote:
* thread_exception::message() is broken beyond repair, as it returns a pointer to local storage (via std::string::c_str())
=8-o . Indeed, it's better to get rid of it. Unless it's actually requested by users, in such case we could introduce std::string member (or something similar) to keep ownership of returned pointer. B.

Short update: I have another patch here, this time against read_write_mutex.cpp, featuring another unused function. The other good news is that I have Boost threads running on a MIPS based embedded system, running on top of MS Windows CE. Changes by this patch: - _sntprintf() uses '%s' for TCHAR strings (char/wchar_t, depends on _UNICODE), while the arguments are always char strings. There is '%S' (capital S!) for the opposite character type. MSC, C99 and SUSv2 disagree in that aspect. - use the same tactic as for TryEnterCriticalSection to determine presence of IsDebuggerPresent() at runtime, so the same lib can run on older systems too and still leverage newer features. - fixed incorrect use of sn[w]printf() for cases the buffer is too small - increased buffer size to a more sensible value (format string ~50, func ~30, file ~MAX_PATH/255, expr ~60) - added newline to message - move boost_error from global namespace to anonymous one - some parts rather depend on the win32 API, not on whether one uses winthreads or pthreads - split off the non-win32 version for better readability However, this whole patch is not even necessary because the whole function is not used (tip: grep for boost_error, this reveals another unused one!). My success above with the MIPS board were made with the code removed, once I saw that the whole thing is not necessary I didn't bother testing it. Yes, I first rewrote the whole thing before realising that it is unused. Uli

Ulrich Eckhardt wrote:
Short update: I have another patch here, this time against read_write_mutex.cpp, featuring another unused function. The other good news is that I have Boost threads running on a MIPS based embedded system, running on top of MS Windows CE.
[snip]
However, this whole patch is not even necessary because the whole function is not used (tip: grep for boost_error, this reveals another unused one!). My success above with the MIPS board were made with the code removed, once I saw that the whole thing is not necessary I didn't bother testing it. Yes, I first rewrote the whole thing before realising that it is unused.
Uli
Thanks. I'm hoping shortly to check in a lot of changes to read_write_mutex.cpp, which has several problems. I'll try to make sure to do something sensible about what you report here. Mike
participants (3)
-
Bronek Kozicki
-
Michael Glassford
-
Ulrich Eckhardt