Date: Mon, 17 May 2021 21:34:33 +0200
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.
> 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
> 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.
> 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
Received on 2021-05-17 14:34:40