Add optional external assertion handler for debug builds

[juanbelonepic]

This PR allows applications to override the default DEBUGASSERT behavior by defining a custom CURL_DEBUGASSERT macro at compile or run time. We needed this to integrate applications where assert is a no-op.

Changes:

• Modified lib/curl_setup_once.h:
  Added check for user-defined CURL_DEBUGASSERT macro before falling back to default assert()
  Allows applications to inject custom assertion handling via compile-time flags

Usage:
Applications can now define their own assertion handler by adding to compiler flags:
-DCURL_DEBUGASSERT(x)="MyAssertHandler(#x, __FILE__, __LINE__);"

And implementing the handler function

extern "C" void MyAssertHandler(const char* expr, const char* file, int line)
{
    // Your custom logging/error handling
}

[dfandrich]

Does this need to be so complicated? Why not simply allow the DEBUGASSERT macro to be redefined as desired at compile time?

[juanbelonepic]

Does this need to be so complicated? Why not simply allow the DEBUGASSERT macro to be redefined as desired at compile time?

I am trying to find a way to replace the macro since we use a precompiled binary of the lib (can't redefine the macro).

[dfandrich]

That's the kind of thing I had in mind. I don't know why the #undef is in there today; the git history that it was just "in case it was already defined" rather than to fix an actual issue. It might be safer to leave the #undef DEBUGASSERT alone and rather allow an external CURL_DEBUGASSERT to override the macro. That way a stray DEBUGASSERT in some system file won't break things; it's much less likely that there would be a stray CURL_DEBUGASSERT around.

[juanbelonepic]

CURL_DEBUGASSERT

We can add this to define DEBUGASSERT based on it, but the lib needs to be built before being used so we can't really redefine the macro, that's why I needed to do a external var , what other options can we think of ? Thanks

[dfandrich]

Just add something like -DCURL_DEBUGASSERT(a)=catch_fire_and_halt(a) to the compiler flags. The application can define catch_fire_and_halt however it wants, at compile time or dynamically at run time.

[juanbelonepic]

User that will benefit from Changes are those who need another custom approach to deal with asserts

[bagder]

I don't understand what this means!

[juanbelonepic]

I don't understand what this means!

I was doing the review, not sure if I need to do that.
The comment means that the changes in this PR are for those who has assert as a no-op or want to redirect them (through the macro) to their custom function.
Thanks

[jay]

If your assert is a no-op isn't that on you to correct and not us? I think if you are going to have to patch libcurl for your custom assertion routine then you could patch the DEBUGASSERT lines as well but in your own fork. I don't see why this needs to be in all libcurl as it seems like a special requirement that only applies to you.

[bagder]

"This branch cannot be rebased due to conflicts"

Please rebase against master and force-push.

[bagder]

Thanks!