bogus warning -Wunused-but-set-variable compiling with clang -DNDEBUG

[j4reporting]

this code generates a warning when compiled with clang and -DNDEBUG

pr_edict.c:886:6: error: variable 'free_edicts_count' set but not used [-Werror,-Wunused-but-set-variable]
886 | int free_edicts_count = 0;
| ^
../Quake/pr_edict.c:887:6: error: variable 'free_list_count' set but not used [-Werror,-Wunused-but-set-variable]
887 | int free_list_count = 0;
| ^
2 errors generated.

changing
free_edicts_count++; to free_edicts_count = free_edicts_count + 1;
free_list_count++; to free_list_count = free_list_count +1;

prevents the warning.

compiling w/o -DNDEBUG prevents the warning because of the assert in line 921
assert (free_list_count == free_edicts_count);

[shafik]

[[maybe_unused]] is the correct way to silence this, cppreference even uses this kind of issue as an example for it's use

[AaronBallman]

Yeah, this is behaving by design and you should use [[maybe_unused]]. The design of -Wunused-but-set-variable is effectively that we count the number of references to the variable and the number of non-ignored assignments to it; if every reference is in an ignored assignment, we diagnose. free_edicts_count++; is not enough for it to be a non-ignored assignment because nothing uses the result of the read (it would be non-ignored if the variable was volatile though). So the only reference ends up being in assert. In the case of free_edicts_count = free_edicts_count + 1;, there is a non-ignored assignment because of the explicit mention of the variable on the RHS of the assignment.

This is the same behavior that GCC has: https://godbolt.org/z/1c6v9feGW (GCC does ignore the volatile case though). While I can see an argument that i++ and i = i + 1 are both doing the same thing and should behave the same way, I think the current behavior of the check is pretty reasonable. Generally, when you explicitly opt-in to -Wunused-but-set-variable you want to know if you wrote i++; and that's the only use of the variable in the function.

Closing the issue because I don't think the behavior of the compiler will change, but feel free to reopen if you'd like to continue the discussion.