C++ Logo


Advanced search

Re: [wg14/wg21 liaison] unreachable control flow

From: Richard Smith <richardsmith_at_[hidden]>
Date: Wed, 19 May 2021 15:35:46 -0700
On Mon, May 17, 2021 at 12:34 PM Jens Maurer via Liaison <
liaison_at_[hidden]> wrote:

> On 17/05/2021 21.12, Miguel Ojeda via Liaison wrote:
> > On Mon, May 17, 2021 at 7:16 PM Jens Gustedt <jens.gustedt_at_[hidden]>
> wrote:
> >>
> >> I am not sure that `abort` tells anything else than this path of
> control flow is catastrophic. So yes, for tiny bit of additional sugar with
> the possible message, but that's it, I think.
> >
> > It tells the reason why the path is not supposed to be reached.
> > Standardizing the most common reasons is a good thing in my view, and
> > I appreciate that Rust has things like `unreachable!`,
> > `unimplemented!`, `todo!`, `panic!`. All of those end up as a panic,
> > but the reason for panicking is different.
> This feels like an additional layer on top of a basic abort().
> That additional layer might not be provided by the C standard
> itself, but by some user library, if so desired.
> > Sure, but in terms of the spec it is not the same, and as a user I
> > would expect different codegen from an optimizer. That is why I would
> > be using an unsafe `unreachable()`, after all.
> >
> >> But what I meant, was that having a feature that behaves fundamentally
> different under debugging makes it impossible to debug the feature when it
> is applied with all of its strength. For me that has much resemblance with
> a nightmare.
> >
> > I agree differing behavior is best avoided in general, but having an
> > easy way to debug all `unreachable()`s in a program (e.g. running the
> > test suite to check nothing hits one of them) seems like a good idea.
> That also feels like an additional layer. Maybe
> #ifdef NDEBUG
> #define assume(b) if (!b) unreachable();
> #else
> #define assume(b) assert(b)
> #endif
> would help here, but the basic facility "unreachable" should
> still be available regardless.

This approach does not make for a good, portable 'assume' implementation.
At least some optimizing compilers will transform

if (!b) unreachable();

... into ...


... without retaining any knowledge that 'b' was assumed to be true. If we
want the functionality of assume(b), we shouldn't assume we get it as a
side-effect of adding unreachable().

> IIRC, some people argued to have this kind of thing within the C++
> > contracts discussions too.
> The C++ contracts discussion got reset after C++20.
> Jens
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/05/0570.php

Received on 2021-05-19 17:36:00