Hi Trent, can you provide me is a minimal example that reproduces this problem? I've tried multiline description just now, and did not get any assertion.
I'd prefer to have a testcase for this bug before fixing it.
The following option triggered the assertion error for me every time: desc.add_options() ("type,t", po::value<string>()->default_value("manual"), "startup type (\"auto\" or \"manual\") (--install only)")); If I reduced the description length such that it fit on a single line, the error went away for that particular option (only to crash on a different multiline option down the track). I was triggering the problem via '--help', which equated to 'cout << desc << endl;'. I've got a pretty vanilla VC++ Express 2005 installation, I haven't done anything out of the ordinary environment wise, which means all the new 'Standard C++ Library Security' features are enabled, so all the _SCL_SECURE_* macros are used. The following line:
395: line_end = line_begin + line_length;
Was being caught by the following macro on line 166 of 'C:\Program Files\Microsoft Visual Studio 8\VC\include\xstring': _Myt& __CLR_OR_THIS_CALL operator+=(difference_type _Off) { // increment by integer if (this->_Mycont != _IGNORE_MYCONT) { _SCL_SECURE_VALIDATE(this->_Mycont != NULL); _SCL_SECURE_VALIDATE_RANGE( _Myptr + _Off <= (((_Mystring *)this->_Mycont)->_Myptr() + ((_Mystring *)this->_Mycont)->_Mysize) && _Myptr + _Off >= ((_Mystring *)this->_Mycont)->_Myptr()); } _Myptr += _Off; return (*this); } Which makes sense, as it's checking we don't assign past the end of our underlying string, which is exactly what line 395 of options_descriptions.cpp does in multiline conditions. If you can't reproduce the assertion in VC8 with the option description I listed above, I'd suggest putting a breakpoint on the _SCL_SECURE_VALIDATE_RANGE() macro above. If it's not being hit (which is what I'd expect), then something in your environment is disabling the _SCL_SECURE* stuff. If it is being hit, yet it's not throwing an assertion, then we have a much more interesting situation on our hands ;-) Regards, Trent. -- http://www.onresolve.com