boost::interprocess::winapi::get_last_bootup_time( std::wstring&)

[Jim Bell <jim@…>]

boost::interprocess::winapi::get_last_bootup_time( std::wstring& strValue )

This line is wrong and is crashing most of the win32 regression tests (both release and trunk):

strValue.erase(strValue.find(L'+'));

strValue doesn't have '+', so .find() returns std::wstring::npos, but that causes std::wstring::erase() to crash. npos isn't a valid parameter to erase() and will cause an out_of_range exception to be thrown. ​http://stdcxx.apache.org/doc/stdlibref/basic-string.html#idx349

I think this is causing many regression test failures both the release and trunk branches for win32.

The fix would be to split it out:

std::wstring::size_type plusPos = strValue.find(L'+');
if (plusPos != std::wstring::npos)
   strValue.erase(plusPos);

I can't speak to why you're looking for a '+' and the significance of not finding it.

[Ion Gaztañaga]

¿Which failures? I see in trunk that some msvc tests are fine:

http://www.boost.org/development/tests/release/developer/interprocess.html

In my machine the string returned from windows WMI is:

20100918163015.375199+120

Maybe depending on the time zone, the offset part (+120 or whatever) is not present. Could you please print string contents to see what is windows WMI returning?

I will applying the patch but I wanted to be sure that it fixes the problem.

[Jim Bell <jim@…>]

My machine returns:

20100923072129.484625-300

60% of the interprocess release tests fail under msvc-8.0 and some other win32 platforms. I think this one bug is causing many of them.

The above npos-check made my test code run. Without it, it crashed.

[Jim Bell <jim@…>]

For the record, I think std::string::erase() ought to handle npos, and I'm disappointed that it doesn't. Your code is more elegant than the fix: it's clear that you don't want to erase anything if you don't find what you're looking for.

[Ion Gaztañaga]

I've committed some changes to trunk, does this solve the problem?

[jim@…]

All trunk tests now pass under msvc-8.0, as you can see from last night's test. Good job!