https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #79 from Andrew Church ---
(In reply to Segher Boessenkool from comment #78)
> If someone (the user, the author, anyone) used warn_unused_result where it is
> not appropriate, just fix *that*. The attribute is specifically for cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #77 from Andrew Church ---
(In reply to Segher Boessenkool from comment #72)
> if (foo()) {
> /* The return value of foo can be ignored here because X and Y. */
> }
This is just another idiom, with "if(){}" replacing "(void)"; it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #70 from Andrew Church ---
(In reply to Jonathan Wakely from comment #69)
> Maybe you want:
>
> [[maybe_unused]] auto _ = foo();
If I could apply that attribute to the value itself, i.e.:
[[maybe_unused]] foo();
that woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #68 from Andrew Church ---
(In reply to uecker from comment #67)
> But also the library could switch to "discard" or add a condition that the
> lets the user of the library choose it.
The issue here is that the library user has no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #66 from Andrew Church ---
(In reply to Andrew Church from comment #65)
> As one of the advocates for this behavior, it stems (at least in my case)
> from pre-C23 code in which [[attribute]] syntax was not available. If
> [[nodiscard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #65 from Andrew Church ---
(In reply to Segher Boessenkool from comment #63)
> So you are asking the compiler to warn whenever you do not use the result
> of a function call, and at the same time you do not use the result of a
> funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #61 from Andrew Church ---
For the record, I'll maintain a copy of my (unaccepted) patch to add
-Wunused-result=strict at: https://achurch.org/patch-pile/#gcc
(wur-strict.diff)
This flag obviously shouldn't be relied on in released p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #53 from Andrew Church ---
(In reply to Segher Boessenkool from comment #51)
> And that is the core of why this issue reinflames once in a while: some
> people
> abuse the attribute, and the compiler cannot read minds.
Ah, for a mind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #48 from Andrew Church ---
(In reply to rusty from comment #47)
> Civility please.
I have no intention of trying to start a fight :) Like you, I'm just trying to
improve the situation, and knowing that in my own open-source work I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #46 from Andrew Church ---
(In reply to Andrew Pinski from comment #45)
> But there is no general agreement at all. If clang behavior agreed with gcc,
> then there would be consensus here. In fact gcc behavior is older than clang
> be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #44 from Andrew Church ---
(In reply to Segher Boessenkool from comment #43)
> That is not the consensus, no. "Consensus" does not mean doing what the
> unthinking masses shout.
Merriam-Webster disagrees:
con.sen.sus
1 a: general ag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #42 from Andrew Church ---
(In reply to Sam James from comment #41)
> Could you send it to the gcc-patches mailing list please? (Even if it is a
> PoC).
Sent as requested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Andrew Church changed:
What|Removed |Added
CC||achurch+gcc at achurch dot org
--- Comme
13 matches
Mail list logo
