refactor: improve assertion macro

This commit is contained in:
Vito
2026-06-04 15:43:24 +02:00
parent 86cfde06d9
commit fb4c2bcc91

View File

@@ -24,12 +24,7 @@
#define XRPL_ASSERT_PARTS(cond, function, description, ...) \
XRPL_ASSERT(cond, function " : " description)
#define XRPL_ASSERT_IF(guard, cond, message) \
do \
{ \
if ((guard)) \
XRPL_ASSERT(cond, message); \
} while (false)
#define XRPL_ASSERT_IF(guard, cond, message) XRPL_ASSERT(!(guard) || (cond), message)
// How to use the instrumentation macros:
//
@@ -38,12 +33,14 @@
// * XRPL_ASSERT_PARTS is for convenience, and works like XRPL_ASSERT, but
// splits the message param into "function" and "description", then joins
// them with " : " before passing to XRPL_ASSERT.
// * XRPL_ASSERT_IF(guard, cond, message) fires the assertion only when guard
// is true (e.g. an amendment is enabled). Equivalent to
// `if (guard) XRPL_ASSERT(cond, message)` but safe to use in all statement
// contexts. NOTE: do not rely on side effects in guard — in release builds
// the assertion body is stripped, and the compiler may optimize away a
// side-effect-free guard entirely.
// * XRPL_ASSERT_IF(guard, cond, message) asserts the implication
// `guard => cond`: it can only fail when guard is true (e.g. an amendment
// is enabled) and cond is false. Unlike `if (guard) XRPL_ASSERT(...)`, the
// assertion site is always evaluated, so the fuzzer registers it
// unconditionally; cond itself is short-circuited and only evaluated when
// guard is true. NOTE: do not rely on side effects in guard — in release
// builds the assertion body is stripped, and the compiler may optimize away
// a side-effect-free guard entirely.
// * ALWAYS if cond must be true _and_ the line must be reached during fuzzing.
// Same like `assert` in normal use.
// * REACHABLE if the line must be reached during fuzzing