[program_options] Bug in program_options with vc-8_0 build target when displaying the help descriptions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[program_options] Bug in program_options with vc-8_0 build target when displaying the help descriptions

boost-7
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
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [program_options] Bug in program_options with vc-8_0 build target when displaying the help descriptions

boost-7
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
>
>
>  [hidden email] 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 [hidden email]
> > http://lists.boost.org/mailman/listinfo.cgi/boost-users
> >
>
>


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users