https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Christian Groessler changed:
What|Removed |Added
CC||groessler_christian at yahoo
dot
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #60 from Segher Boessenkool ---
(In reply to Roman Krotov from comment #59)
> All, what I'm asking for, is to make something like -Wno-void-unused, which
> would suppress the warnings only for the (void) casted calls.
So you want to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #59 from Roman Krotov ---
(In reply to Ed Catmur from comment #58)
> (In reply to Roman Krotov from comment #57)
I already addressed all of it in my previous 2 comments...
I'll write more clearly then.
> > But I don't see any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #58 from Ed Catmur ---
(In reply to Roman Krotov from comment #57)
> But I don't see any reasons not to implement the switch right now...
Making [[gnu::warn_unused_result]] mean the same as [[nodiscard]] would be a
reduction in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #57 from Roman Krotov ---
(In reply to Ed Catmur from comment #55)
> So this problem will resolve itself, over time.
But I don't see any reasons not to implement the switch right now...
Late is better than never.
> we can expect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #55 from Ed Catmur ---
(In reply to Roman Krotov from comment #54)
[[nodiscard]] is in C23, so we can expect that attribute to be adopted where
people intend that behavior (warning suppressible by cast to void) as opposed
to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Roman Krotov changed:
What|Removed |Added
CC||romato.san1337 at gmail dot com
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #52 from Jan Engelhardt ---
>This is useful for functions where not checking the
>result is either a security problem or always a bug, such as
>'realloc'.
always? reall..y..oc?
void *x = malloc(1);
realloc(x, 0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #51 from Segher Boessenkool ---
(In reply to rusty from comment #47)
> Civility please.
Thank you.
> As Andrew Pinski says "people are mis-using this attribute", and Jakub
> Jelinek makes a similar point. The use of _wur has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #50 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #49)
> All that means is for APIs for which cast to void as silencing is meant to
> be ok should be using [[nodiscard]] rather than
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #49 from Jakub Jelinek ---
All that means is for APIs for which cast to void as silencing is meant to be
ok should be using [[nodiscard]] rather than
__attribute__((warn_unused_result)). APIs which do not want that should keep
using
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #47 from rusty at rustcorp dot com.au ---
Civility please.
We're all trying to find a path to improve things here. But accept that the
conversation on this issue is only a weak indication of consensus.
As Andrew Pinski says "people
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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #45 from Andrew Pinski ---
(In reply to Andrew Church from comment #44)
> (In reply to Segher Boessenkool from comment #43)
> > That is not the consensus, no. "Consensus" does not mean doing what the
> > unthinking masses shout.
>
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #43 from Segher Boessenkool ---
(In reply to Andrew Church from comment #40)
> My rationale for changing the default behavior is that the wider community
> consensus, as evidenced by things like the C++ (and C2x) [[nodiscard]]
>
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
--- Comment #41 from Sam James ---
(In reply to Andrew Church from comment #40)
> Created attachment 54906 [details]
> POC patch to add -Wunused-result=strict
>
Could you send it to the gcc-patches mailing list please? (Even if it is a
PoC).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Andrew Church changed:
What|Removed |Added
CC||achurch+gcc at achurch dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Andrew Pinski changed:
What|Removed |Added
CC||porton at narod dot ru
--- Comment #37
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #36 from Jason Merrill ---
(In reply to Jason Merrill from comment #35)
> Is there a reason you can't use [[nodiscard]]?
...ah, because this is a bug report against the C compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #35 from Jason Merrill ---
Is there a reason you can't use [[nodiscard]]?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Ed Catmur changed:
What|Removed |Added
CC||ed at catmur dot uk
--- Comment #34 from Ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #33 from costinc at gmail dot com ---
There are legitimate reasons to ignore results, even without additional
comments.
One use case I ran into is:
// ok() checks the same condition as the one returned by f().
while (ok()) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #32 from Segher Boessenkool ---
Yes, it does hurt. Quite many people use casts to void automatically on
all function calls where they do not use the result. They of course need
to be re-educated on that. Casts to void do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #31 from Hans Ecke ---
I would like to point out that what everybody here proposes - make (void) work
properly with WUR - hurts no one. The other viewpoint has only given vague
theoretical reasons. Let me give you something concrete:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Yongwei Wu changed:
What|Removed |Added
CC||wuyongwei at gmail dot com
--- Comment #30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Andrzej Krzemienski changed:
What|Removed |Added
CC||akrzemi1 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Adam Borowski changed:
What|Removed |Added
CC||kilobyte at angband dot pl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #25 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #24)
> I agree that (void) should suppress the warning. Jakub, do you remember why
> you made a different choice?
I think the request came from Uli that it isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Jason Merrill changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
costinc at gmail dot com changed:
What|Removed |Added
CC||costinc at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #22 from Filipe Brandenburger filbranden at google dot com ---
(In reply to Jan Engelhardt from comment #20)
Seems like the short route is to add a new attribute
((warn_unused_result_with_void_cancelling)) that exhibits the desired
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #21 from rusty at rustcorp dot com.au ---
jengelh at inai dot de gcc-bugzi...@gcc.gnu.org writes:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #20 from Jan Engelhardt jengelh at inai dot de ---
Seems like the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #20 from Jan Engelhardt jengelh at inai dot de ---
Seems like the short route is to add a new attribute
((warn_unused_result_with_void_cancelling)) that exhibits the desired
behavior of (void) cancelling the warning, and then make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Segher Boessenkool segher at gcc dot gnu.org changed:
What|Removed |Added
CC||segher at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #19 from rusty at rustcorp dot com.au ---
I like WUR as a sanity-check, and it is useful that more and more library
authors are using it (generally quite well). As Andrew points out, this has
taken 10 years! The downside is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
Some remarks before the discussion gets out of hand.
Neither Andrew nor me nor other people that may comment here have the power to
approve or reject this change. The people
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #13 from Andreas Schwab sch...@linux-m68k.org ---
I don't really see why the trouble making the mental connection from the
void cast with the coder's intent do discard that result. Could it mean
anything else really?
The C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #15 from Lucas De Marchi lucas.de.marchi at gmail dot com ---
(In reply to Manuel López-Ibáñez from comment #14)
(In reply to Filipe Brandenburger from comment #12)
Can I have this issue reopened please?
If that makes you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #12 from Filipe Brandenburger filbranden at google dot com ---
(In reply to Manuel López-Ibáñez from comment #11)
Neither Andrew nor me nor other people that may comment here have the power
to approve or reject this change.
Great,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Filipe Brandenburger from comment #6)
Then please explain to me how this:
(void) foo();
is any worse than this:
int ignored __attribute__((unused));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #8 from Filipe Brandenburger filbranden at google dot com ---
(In reply to Andrew Pinski from comment #7)
Again this has nothing to do with other lints, this attribute was designed
so you can't ignore the return value.
I obviously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #9 from Filipe Brandenburger filbranden at google dot com ---
Or, conversely, please explain to me how changing the behavior (to allow a
void-cast to silent the warning on a call to a warn_unused_result function)
would actually affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Lucas De Marchi lucas.de.marchi at gmail dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #16 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
I'd say that for any function for which use of this attribute is
appropriate, suppression of the warning should involve a detailed comment
explaining why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #17 from Filipe Brandenburger filbranden at google dot com ---
To make matters even worse, gcc doesn't even seem to be consistent with itself,
because in other situations it *does* accept a cast to void to silent warnings.
For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Filipe Brandenburger filbranden at google dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #3 from rusty at rustcorp dot com.au ---
Indeed, cast to void has been a standard I really want to ignore this
notation. It's intuitive and obvious, and ISTR seeing it in the early 90s for
lint warning suppression, for example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Konstantin Khlebnikov koct9i at gmail dot com changed:
What|Removed |Added
CC||koct9i at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #6 from Filipe Brandenburger filbranden at google dot com ---
Then please explain to me how this:
(void) foo();
is any worse than this:
int ignored __attribute__((unused));
ignored = foo();
/* do nothing with ignored here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
62 matches
Mail list logo
