On 3/18/10, Markus Armbruster <arm...@redhat.com> wrote:
> Blue Swirl <blauwir...@gmail.com> writes:
>
> > On 3/18/10, Markus Armbruster <arm...@redhat.com> wrote:
> >> Blue Swirl <blauwir...@gmail.com> writes:
> >>
> >> > On 3/17/10, Markus Armbruster <arm...@redhat.com> wrote:
> >> >> Blue Swirl <blauwir...@gmail.com> writes:
> >> >>
> >> >> > On 3/17/10, Markus Armbruster <arm...@redhat.com> wrote:
> >>
> >> [...]
> >>
> >> >> >> +void monitor_set_error(Monitor *mon, QError *qerror)
> >> >> >> +{
> >> >> >> + assert(0);
> >> >> >
> >> >> > Please use abort().
> >> >>
> >> >>
> >> >> Why?
> >> >
> >> > Because assert(0) does not abort when compiled with -DNDEBUG.
> >>
> >>
> >> Why is that a problem? And why isn't it a problem for the 300+ other
> >> assertions in the code?
> >
> > We didn't support -DNDEBUG build until recently. Therefore it's safe
> > to assume that also on production builds assert(0) was equal to
> > abort(). If the default for production builds changes to -DNDEBUG, we
> > want to retain the same abort() behaviour.
> >
> > The assertions which perform debugging checks aren't a problem. But
> > assert(0) clearly isn't a debugging check, if you ever reach this line
> > of code, it's abort() time.
>
>
> I *know* that this line cannot be reached. That's why I asserted it
> cannot be reached.
>
> If you want "this can't ever happen" assertions to be checked, then you
> shouldn't define NDEBUG.
If you know for sure that this line can't be reached, why bother with
any code at all?
> Do you still want me to use abort() here?
abort() or nothing at all, as you wish.
> By the way, a quick grep shows >50 uses of assert(0).
Not anymore since 43dc2a645e00e6761a741e3d16c27c5b5a373b66.
