Re: [Boost-users] Program_options assertion failure

From: Hughes, James (jhughes_at_[hidden])
Date: 2007-08-29 11:25:03

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] 
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of 
> Vladimir Prus
> Sent: 17 July 2003 15:46
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] Program_options assertion failure
> 
> Johnathan Bunn wrote:
> 
> > im having an issue with a project using visual studio pro 2005
> > 
> > if it makes a difference the librarys im using are Qt, 
> pdflib, boost, 
> > and some crystal com stuff thorugh activex
> > 
> > my problem is that when I build in release my command line args are 
> > parsed fine and my application behaves as expected.
> > 
> > when I build in debug mode, I get an asertion failure as follows
> > 
> > Assertion failed: n == name.size()-2, file 
> > libs\program_options\src\options_description.cpp, line 122
> 
> Well, here's the code where assert happens:
> 
>     option_description&
>     option_description::set_name(const char* _name)
>     {
>         std::string name(_name);
>         string::size_type n = name.find(',');
>         if (n != string::npos) {
>             assert(n == name.size()-2);
>             m_long_name = name.substr(0, n);
>             m_short_name = '-' + name.substr(n+1,1);
>         } else {
>             m_long_name = name;
>         }
>         return *this;
>     }
> 
> We have identified that _name is "help,h", and the 'n' 
> variable ends up as 8 -- which is twice as much as I've 
> expected. There's some Unicode option enabled in project 
> settings, but I have no idea why that would affect char* values. 
>         
> > I am completely stumped and sought help on the #boost irc channel
> > 
> > volodya and others on that channel were stumped as well
> 
> Yeah, I have no idea about this MSVC behaviour, so if some 
> msvc user has any input, that would be great.
> 
> - Volodya
> 

I don't have VC2005 so cannot try this, but I would suggest debugging
through at the disassembly level and seeing what's happening in the
registers, and hence where the 8 comes from - perhaps a bad type
conversion somewhere - that would show up a compiler fault. Usual
difference between release and debug on VS is that debug code has better
default initialisation of variables, but the code look fine. I would
suspect a compiler issue, I've certainly seem similar when using older
versions of VS.

Actually a thought just occurred - are the libraries built with a
different unicode setting to the application, which may affect the
definition (and bit size) of the string::size_type (guessing....)? Check
the return value (at register level) from name.find() and compare with
what is assigned to n.

James

This message (including any attachments) contains confidential 
and/or proprietary information intended only for the addressee.  
Any unauthorized disclosure, copying, distribution or reliance on 
the contents of this information is strictly prohibited and may 
constitute a violation of law.  If you are not the intended 
recipient, please notify the sender immediately by responding to 
this e-mail, and delete the message from your system.  If you 
have any questions about this e-mail please notify the sender 
immediately.