ARCHIVE/rippled
1
0
Fork 0
mirror of https://github.com/XRPLF/rippled.git synced 2026-06-03 00:36:48 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: Correct XRPL_ASSERT_IF comment on guard evaluation

Browse Source 
The previous wording claimed guard is always evaluated in release builds,
but a side-effect-free guard may be optimized away when the assertion
body is a no-op. Reword to warn callers not to rely on side effects
rather than making an unconditional evaluation guarantee.
This commit is contained in:
Vito
2026-06-02 12:58:51 +02:00
parent f9f07704d2
commit 23dc3b2cbb
1 changed files with 3 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
include/xrpl/beast/utility/instrumentation.h
View File

@@ -41,8 +41,9 @@
// * 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: guard is always evaluated — even in release builds where
// the assertion itself is stripped — so keep it side-effect-free and cheap.
// 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.
// * 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