Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Commit message and code mismatch regarding macro evaluation and return type. --
commit 540d64bf950ba97fca84806f776637334569e3d7 Author: Jim Cromie <[email protected]> Subject: dyndbg: add DEBUG-biased fallback stubs for _dynamic_func_call_cls This commit adds fallback stubs for the _dynamic_func_call_cls family of macros when dynamic debug is disabled. It ensures that subsystems wrapping these functions do not fail to build due to implicit declarations. Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ > If DEBUG is not defined, they use an if (0) statement-expression to compile > out the call while returning 0, achieving zero overhead while maintaining > compile-time argument checking. > diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h > --- a/include/linux/dynamic_debug.h > +++ b/include/linux/dynamic_debug.h [ ... ] > +#else > +#define _dynamic_func_call_cls(cls, fmt, func, ...) \ > + do { if (0) func(NULL, ##__VA_ARGS__); } while (0) > +#define _dynamic_func_call_cls_no_desc(cls, fmt, func, ...) \ > + do { if (0) func(__VA_ARGS__); } while (0) > +#endif [Severity: Medium] Is there a discrepancy here between the commit message and the implementation? The commit message states that the fallback stubs in include/linux/dynamic_debug.h use a statement-expression to return 0. However, the actual implementation of _dynamic_func_call_cls uses a do-while(0) loop, which evaluates to void rather than 0. Since these macros are typically used as statements, evaluating to void seems functionally correct for compilation. Could the commit message be updated to accurately reflect the do-while(0) implementation to avoid confusion? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=42
