https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389
--- Comment #6 from felix <felix.von.s at posteo dot de> ---
I don’t mind the transformation being applied. I think it is entirely sound and
may be beneficial; I imagine it may be harder to allocate registers for the
naïve translation of (foo() ? X : X) than it is for (foo(), X). It’s just the
warning that is wrong.
> So, use [[nodiscard]] instead
This is filed against the C frontend, where [[nodiscard]] has not been
implemented. Not even on trunk (as provided today by godbolt.org, at least).
You are asking people to use a feature that does not exist.
Even if [[nodiscard]] is going to be added eventually, most code in the wild
uses __attribute__((warn_unused_result)) and will do so for a while. Which
means it will still be subject to false positives like this one.
Moreover, the attribute often appears in library headers, which the library
user is not really at liberty to change. Are you suggesting that everyone
compile their code with -Dwarn_unused_result=nodiscard
-D__warn_unused_result__=nodiscard passed on the command line? Will that even
work?
Maybe you should reflect for a while on why the C++ and C committees considered
it more useful to standardise [[nodiscard]] with the semantics they did,
instead of the semantics of GCC’s __attribute__((warn_unused_result)) as of
today.
> O_TEXT != 0 ? text_mode () ? O_TEXT : 0 : 0
First of all, that is not equivalent:
int text_mode(void) {
if (mode == MODE_TEXT) {
fprintf(log_file, "text mode selected\n");
return 1;
} else {
fprintf(log_file, "binary mode selected\n");
return 0;
}
}
Maybe I care about that log message, even in the case where the return value
itself happens to be ultimately irrelevant.
Second of all, I should not be faulted for not adding redundant special cases
to my already correct code. I am not going to add convoluted hacks just to
avoid an asinine compiler warning. I do not want to hand-optimise
platform-specific cases like this either; taking care of platform-specific
serendipities that can be exploited for optimisation purposes is the compiler’s
job.
And finally, just because a faulty workaround exists doesn’t make the warning
not wrong. If GCC cannot tell a legitimate use from ‘obfuscation’, it should
err on the side of the former. (I believe a case could be made for multiplying
by zero as well.)
Though I think it would be simpler to just make the semantics of
__attribute__((warn_unused_result)) be exactly like [[nodiscard]].
