Re: [boost] [program_option, throw_exception] misterious borland failures

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-06-06 14:25:41

Vladimir Prus wrote:
> Hello,
> I've tried to dig into program options runtime failures on borland.
> Consider this code, from cmdline.cpp (cmdline::finish_option):
>
>  const option_description* xd =
>            m_desc->find_nothrow(opt.string_key, (m_style &
> allow_guessing));
>
>        if (!xd)
>        {
>            if (m_allow_unregistered) {
>                opt.unregistered = true;
>                return;
>            } else {
>                throw_exception(unknown_option(opt.string_key));
>            }
>        }
>        const option_description& d = *xd;
>
> Running in the debugger, I see that 'xd' is NULL,
> m_allow_unregistered is false, and the execution arrives on
> "throw_exception". After that, *nothing happens*, and program goes on
> dereferencing null pointer and using the obtained reference.

Evil.

> If I replace throw_exception with "throw", the tests fails later, and
> if I replace all throw_exception's with throw in the module, test
> passes.
>
> So I have two questions:
>
> 1. Did anybody else had this problem with throw_exception
> 2. If throw_exception function does not work with borland, maybe it
> should become macro on that compiler?

throw_exception can't be a macro because it can be called with boost:: 
qualification. In fact, try using boost::throw_exception in the code above; 
I remember hitting a similar code generation bug in Boost.Bind, take a look 
at the beginning of boost/bind.hpp.