Hi Will, thanks for the answer. I still ask myself what is the correct way of handling these situations with the new standard library. I had a similar issue in my own software and I didn't liked the solution to fall back to manually track the array bounds. The only way to write this line safe would be:

if (par_end - line_begin < line_length - indent)

in order to compute a distance between the two involved iterators. But is this really better? Is the old line really a safety problem? Or is this type of problem the penalty one have to pay for the enhanced security in other areas? Best regards Dirk Will Bryant schrieb:

Hmm, Vladimir Prius doesn't seem to be responding on the list at the moment, but FWIW this is a known bug - see my November 2005 posts about it in the mailing list archive. Vladimir was working on a fix, but the last version he sent still had the problems...

Will

boost@nogga.de wrote:

...

Hello,

there is a bug in the help output generated from

void format_paragraph(std::ostream& os, std::string par, unsigned first_column_width, unsigned line_length)

function. The error message is cryptic and something like that:

_Myptr + _Off <= (((_Mystring *)this->_Mycont)->_Myptr() + ((_Mystring *)this->_Mycont)->_Mysize) && _Myptr + _Off >= ((_Mystring *)this->_Mycont)->_Myptr():

The point is that the new vc8.0 compiler (or better the vs2005 standard library) performs a lot of additional iterator checking. In the function format_paragraph the "line_begin" iterator is checked, whether there is one more line to indent in the help output or whether this is the last line. During this process, the "line_begin" iterator is incremented behind the end of the current string "par.end()" and this will trigger the _SCL_SECURE_VALIDATE_RANGE warning from the new library.

if (line_begin + (line_length - indent) > par_end) { line_end = par_end; }

You should be able to trigger this behavior with every application when printing the help text for an option that is longer than one line.

This new iterator checking has it's pros and cons. While it is good to find any sort of error, how would you safely write the case above without reverting to index like operations?

Best regards Dirk _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users