|
Boost Users : |
From: boost_at_[hidden]
Date: 2006-02-10 14:25:23
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_at_[hidden] 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_at_[hidden]
> > http://lists.boost.org/mailman/listinfo.cgi/boost-users
> >
>
>
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net