On 2025-03-14 at 01:06:21, Junio C Hamano wrote: > "Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > diff --git a/git-compat-util.h b/git-compat-util.h > > index c3415ad7e0a..0aefd763751 100644 > > --- a/git-compat-util.h > > +++ b/git-compat-util.h > > @@ -1584,4 +1584,10 @@ static inline void *container_of_or_null_offset(void *ptr, size_t offset) > > ((uintptr_t)&(ptr)->member - (uintptr_t)(ptr)) > > #endif /* !__GNUC__ */ > > > > +#ifdef CHECK_ASSERTION_SIDE_EFFECTS > > +#undef assert > > +extern int not_supposed_to_survive; > > +#define assert(expr) ((void)(not_supposed_to_survive || (expr))) > > +#endif /* CHECK_ASSERTION_SIDE_EFFECTS */ > > Cute. As this checking assert is in void context, the optimizing > compiler knows that the entire thing can be optimized away ONLY IF > it can somehow prove that (expr) has no side effect. And if it does > not optimize it away, you will hit an error from the linker, saying > that the undefined variable is being used. I agree this is very clever. > This requires a fairly good optimizing compiler that can peek into > (as in "inline") what is in expr to notice, so it cannot be free of > false positive, but at least when the optimization works as expected, > it is provably (modulo optimizer bugs) side-effect free. > > Is this something we can use in our project? I am just double > checking. I believe it's valid in C99. Certainly some compiler might be bad at optimizing, or a user may have compiled with -O0, but this is run in CI, where we have known good compilers and can control the optimization flags. I doubt GCC, Clang, or MSVC will have problems here, and since this is not on by default, users using something less capable (the Tiny C Compiler, maybe?) or a vendor compiler won't even see it. Was there some other case that you were concerned about? -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
