Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: dbg_break macro
Date: Fri, 7 Jun 2024 09:55:09 +0200
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <v3uect$1vrug$1@dont-email.me>
References: <v3ptto$vgqm$1@dont-email.me>
 <pan$c5a7f$519c50bb$a44bc8ca$b7510c5d@invalid.invalid>
 <v3t6ru$1jpih$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 07 Jun 2024 09:55:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ec5c1f9082215424827ae25d429fe7a7";
	logging-data="2093008"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+LzxefXJFtTzdK2QQo1y94ASLdvDIKGps="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:QOnns4DSBRm2OQnp9fG4OCJbgKs=
In-Reply-To: <v3t6ru$1jpih$2@dont-email.me>
Content-Language: en-GB
Bytes: 3630

On 06/06/2024 22:40, Thiago Adams wrote:
> On 06/06/2024 17:10, Blue-Maned_Hawk wrote:
>>
>> I feel like you would probably want to be using a debugger to set your
>> breakpoints, although the Clang dialect of C does have a
>> __builtin_debugtrap builtin subroutine.
>>

And gcc has __builtin_trap, which will have a similar effect.

>>
>>
> 
> 
> C++ 26 will have breakpoint. Lot of links about how to do that.
> https://en.cppreference.com/w/cpp/utility/breakpoint
> 
> But, thinking about my usage, the source line, message, etc., everything 
> that assert has is useful. What is not useful is to pass a constant 
> expression for something that is supposed to be a runtime check.
> 
> I remember when I thought that static_assert could just be assert 
> because it is not hard for the compiler to know when we have a constant 
> expression or not. If we have a constant expression, this should be just 
> like static_assert.

A major point (for me, at least) about static_assert is that it is 
/always/ compile-time.  Thus I know it never has any run-time overhead.

I have also used macros that make use of gcc's "__builtin_constant_p()" 
function so that the compiler checks at compile-time if it can, 
regardless of any debug options, but won't normally add any run-time 
checks unless I am setting options to check for some specific issue.

> 
> assert(2 == 2); // compile-time check
> 
> If the expression is not constant, then it would be checked at runtime 
> during debugging.
> 
> This idea fails fast, when we think assert is used with assert(0);

Personally, I can't see any use for an assertion that is always known to 
fail.  It makes no sense to me - it's a claim "this statement is not 
true".  I have no problem with having checks and handling situations 
that should never occur, especially during development and testing 
phases of the program.  But the appropriate response might be to reset 
the board, invoke the debugger, log an error message and restart, halt 
and catch fire, or panic, and the macro or function should reflect that. 
  Simply denying reality and fundamental logic by declaring that 0 is 
true is /not/ an appropriate response.


> 
> I think dbg_break also transmit the idea that the branch is possible 
> while assert(0) can be confusing.
> 

Certainly dbg_break is a better name, IMHO.  But I'd want a reason for 
the halt, especially if you are not running the code under a debugger at 
the time.