1. Forum
  2. Usenet
  3. COMP.LANG.C

  • Re: dbg_break macro

    From Kaz Kylheku@21:1/5 to Thiago Adams on Thu Jun 6 16:17:27 2024
    On 2024-06-05, Thiago Adams <[email protected]> wrote:
    Checking the usages of assert(0) in my code it is used to create a
    breakpoint in unusual situations. Sample

    if (condition) {

    }
    else {
    assert(0); //unexpected
    return 1;
    }

    It's just too much boilerplate, and in the end you you get a "assertion
    0 failed in foo.c:42".

    Prefer:

    assert (condition);

    The "return 1" is only reachable if assertions are turned
    off with NDEBUG. If you need that, make your own assert macro.

    I am thinking in replacing all my assert(0) for this macro.

    #define dbg_break(message) assert(! "dbg_break" message );

    if (condition) {

    }
    else {
    dbg_break("unexpected");
    return 1;
    }

    The message "unexpected" is still unrelated to condition,
    and you have all the boiler-plate. It could all be packaged
    into some kind of:

    dbg_break_ret(condition, 1);

    if the condition is false, there is a debug break, but in
    some mode of compilation, the alternative return is
    executed.


    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @[email protected]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Blue-Maned_Hawk@21:1/5 to All on Thu Jun 6 20:10:17 2024
    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.



    --
    Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site
    Rated for one amp, so i'm going to be doing five of those…

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Thiago Adams on Fri Jun 7 09:55:09 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to David Brown on Fri Jun 7 14:09:45 2024
    David Brown <[email protected]> writes:
    On 06/06/2024 22:40, Thiago Adams wrote:


    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.

    In our software the use of the ASSERT macro is forbidden. That
    doesn't mean that we don't check for certain 'impossible' conditions,
    it means that when such a condition is detected, some other means
    must be used to report and recover from it.

    There's nothing a customer hates more than their multi-hour run just terminating with an assertion.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)