Date: Sat, 8 May 2021 12:04:05 -0700
On Sat, May 8, 2021 at 11:52 AM Nevin Liber via SG12 <sg12_at_[hidden]>
wrote:
> On Thu, May 6, 2021 at 6:47 PM JF Bastien via SG12 <sg12_at_[hidden]>
> wrote:
>
>> Compilers diagnose when functions can't be proved to return, and I
>> wouldn't work on a codebase without this diagnostic enabled as an error. Is
>> there a valid reason to keep this UB around?
>>
>
> How does one write an assert-type macro which, when it is disabled, still
> prevents this type of warning/error? Because people do write:
>
> my_assert(false);
>
> to mean abort in debug mode, take my chances in release mode.
>
I don’t think I understand what you’re asking... but it sounds like
#ifdef _DEBUG
#define YOLO() abort()
#else
#define YOLO() std::unreachable() // or __builtin_unreachable()
But I don’t know what you’re going for, and whether this is what you’re
asking.
>
wrote:
> On Thu, May 6, 2021 at 6:47 PM JF Bastien via SG12 <sg12_at_[hidden]>
> wrote:
>
>> Compilers diagnose when functions can't be proved to return, and I
>> wouldn't work on a codebase without this diagnostic enabled as an error. Is
>> there a valid reason to keep this UB around?
>>
>
> How does one write an assert-type macro which, when it is disabled, still
> prevents this type of warning/error? Because people do write:
>
> my_assert(false);
>
> to mean abort in debug mode, take my chances in release mode.
>
I don’t think I understand what you’re asking... but it sounds like
#ifdef _DEBUG
#define YOLO() abort()
#else
#define YOLO() std::unreachable() // or __builtin_unreachable()
But I don’t know what you’re going for, and whether this is what you’re
asking.
>
Received on 2021-05-08 14:04:21