I wonder if renaming CURLDEBUG to something else would help avoiding
regressions and improve readability? Its use spans accross many components,
and there is even a public symbol mentioning it, making a change somewhat
involved, but doable.

New name could be CURL_MEMDEBUG? (there is a related env with this
name used by tool_main and runtests, for CURLDEBUG builds.)

Would this be desired and useful?

I wonder if renaming CURLDEBUG to something else would help avoiding regressions and improve readability? Its use spans accross many components, and there is even a public symbol mentioning it, making a change somewhat involved, but doable.

New name could be CURL_MEMDEBUG? (there is a related env with this name used by tool_main and runtests, for CURLDEBUG builds.)

Would this be desired and useful?

CURLDEBUG is used for more than memdebug. I think the rename would be confusing.

I wonder if renaming CURLDEBUG to something else would help avoiding regressions and improve readability? Its use spans accross many components, and there is even a public symbol mentioning it, making a change somewhat involved, but doable.
New name could be CURL_MEMDEBUG? (there is a related env with this name used by tool_main and runtests, for CURLDEBUG builds.)
Would this be desired and useful?

CURLDEBUG is used for more than memdebug. I think the rename would be confusing.

True, strictly speaking. It also tracks open/close and
getaddrinfo/freeaddrinfo.

The feature is called "Track Memory" in public messages, also
missing the two extra tracked things. The primary (or initial)
focus was on memory.

IMO CURL_MEMDEBUG is an improvement over CURLDEBUG,
which is vague and caused mis-uses in the past, but I'm not
insisting on that particular name. (One advantage is that it has the
word DEBUG, along with DEBUGBUILD, helping greps.)

What would be a better name?

edit: CURL_RESDEBUG?

What's DEBUGBUILD even for?

I suspect that the source of the confusion is that we have two separate defines, and that all of us who ever debug curl have both set in debug builds.

DEBUGBUILD: makes a "debug-enabled" curl with all the hooks and special code to inject settings, values, etc, also for some runtests to run.
CURLDEBUG: Track Memory, which also includes tracking open/close and get/freeaddrinfo.

DEBUGBUILD by default implies CURLDEBUG, but they can be set separately.

Merging CURLDEBUG into DEBUGBUILD could fix with the confusion, and reduce build combinations, though it'd also mean that it's not possible run the full test suite with the production non-memdebug low-level functions. There is one such job in CI (on Linux), and can't off-the-bat decide if losing this is a real loss or not.

edit2: also the reverse, someone may want to trace memory in a production build? Can't say how useful that is. Probably not very common because it's been untangled relatively recently and was broken earlier. Perhaps another data point is that memdebug is now (since 2025 autumn) "cleanly" implemented and unlikely to cause a build issue in any configuration. Meaning enabling it has no longer this potential drawback.

edit: If merging, one way to go is remove build-level knobs, public facing separate "Track Memory" setting, and internally guard the few CURLDEBUG things with an internal macro bound to DEBUGBUILD (to allow grepping for these code parts). But for all intents and purposes, a debug-enabled build would unconditionally feature Track Memory.

patch proposal: #20331