On 22/05/2026 08:08, Alejandro Colomar wrote:
> Hi Jonathan,
>
> On 2026-05-21T23:47:08+0100, Jonathan Grant wrote:
>>> That ship has sailed for unreachable(), I fear. While I would have
>>> liked unreachable() to be that tool, I don't think we can do that now.
>>>
>>> But we could add a new tool, a 'trap' statement, that would be diagnosed
>>> if it is not optimized out (maybe as recommended practice).
>>>
>>> trap; // diagnosed unless proved unreachable.
>>>
>>>
>>> Have a lovely night!
>>> Alex
>>
>> Hi Alex
>>
>> That's a shame re unreachable()
>>
>> Is this the idea Martin Uecker __builtin_trap_msg("xyz") mentioned? He said he had a patch for GCC.
>> I don't think a good idea to name a feature that issues diagnostic
>> warnings a "trap", would confuse with existing debugger terminology.
>
> The name trap is precisely because it would trap at run time. So, the
> name is quite appropriate, I think.
>
> Of course, nobody wants their programs to trap, so it would make sense
> to diagnose a trap if it isn't optimized out.

Ok i see. yes, a diagnostic warning of every trap (SIGTRAP) etc or abort() call left in an ELF would be useful to see.

Kind regards
Jonathan

>> Someone talking about a similar named builtin on llvm, but it still needs the compiler to output a diagnostic (not just trap at runtime)
>> https://discourse.llvm.org/t/rfc-adding-builtin-verbose-trap-string-literal/75845/19
>
>
> Have a lovely day!
> Alex
>