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 #35 from Jason Merrill ---
Is there a reason you can't use [[nodiscard]]?
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
Yongwei Wu changed:
What|Removed |Added
CC||wuyongwei at gmail dot com
--- Comment #30
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
--- 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 portab
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()) {
switc
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
Andrzej Krzemienski changed:
What|Removed |Added
CC||akrzemi1 at gmail dot com
--- Comm
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
--- C
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
--- 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 tha
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
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Christian Groessler changed:
What|Removed |Added
CC||groessler_christian at yahoo
dot d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Andrew Church changed:
What|Removed |Added
CC||achurch+gcc at achurch dot org
--- Comme
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
--- 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 #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]]
> speci
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 #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 #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 #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 #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 #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 #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
> __attribute__((warn_unused_resul
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 change
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 #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
Andrew Pinski changed:
What|Removed |Added
CC||porton at narod dot ru
--- Comment #37 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Roman Krotov changed:
What|Removed |Added
CC||romato.san1337 at gmail dot com
--- Comme
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 nonpo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #56 f
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 tha
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 expres
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 reasons
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 #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
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Filipe Brandenburger changed:
What|Removed |Added
CC||filbranden at google dot com
---
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
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Konstantin Khlebnikov changed:
What|Removed |Added
CC||koct9i at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #6 from Filipe Brandenburger ---
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 */
You can force me to assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #7 from Andrew Pinski ---
(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));
> ignored = foo();
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #8 from Filipe Brandenburger ---
(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 *can* ignore the return val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #9 from Filipe Brandenburger ---
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 anyone today...
If it's a p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Lucas De Marchi changed:
What|Removed |Added
CC||lucas.de.marchi at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #11 from Manuel López-Ibáñez ---
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 you need to convince are t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #12 from Filipe Brandenburger ---
(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, so please don't preemptivel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #13 from Andreas Schwab ---
> 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 language doesn't define an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Manuel López-Ibáñez changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
CC|man
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #15 from Lucas De Marchi ---
(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 happy...
>
> > Ok, how can we ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #16 from 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 the particular use of the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #17 from Filipe Brandenburger ---
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 example, -Wunused-but-set-variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
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 fals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #20 from Jan Engelhardt ---
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 glibc use that.
Simple,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #21 from rusty at rustcorp dot com.au ---
jengelh at inai dot de writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
>
> --- Comment #20 from Jan Engelhardt ---
> Seems like the short route is to add a new attribute
> ((warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #22 from Filipe Brandenburger ---
(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"
> behavior of (void) canc
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
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #63 from Segher Boessenkool ---
(In reply to Christian Groessler from comment #62)
> (In reply to Segher Boessenkool from comment #60)
> > So you want to not warn for some (just *some*) explicitly unused cases, and
> > do
> > warn for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
---
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 #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 #67 from uecker at gcc dot gnu.org ---
(In reply to Andrew Church from comment #66)
> (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 w
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 #69 from Jonathan Wakely ---
(In reply to Andrew Church from comment #68)
> I do agree that "(void)" is very idiomatic, and something like a [[discard]]
> statement attribute (which would silence warnings for both
> __attribute__((wur
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 #71 from Petr Skocik ---
An Ignore macro that works everywhere where a (void) cast syntactically works
(i.e., even on void types for whatever reason) is easy:
#define IGN$(Val) (__extension__({ \
__auto_type IGN$ = _Generic((typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #72 from Segher Boessenkool ---
The correct way to not get the warning about unused results, is to _do_ use
the function return value, of course, as I explained in #c18 already.
Like:
if (foo()) {
/* The return value of foo can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #73 from Zdenek Sojka ---
See MISRA C:2012 Rule 17.7:
"... If the return value of a function is intended not to be used explicitly,
it should be cast to the void type. ..."
It would be helpful if gcc could be used to write MISRA-com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #74 from Florian Weimer ---
(In reply to Zdenek Sojka from comment #73)
> See MISRA C:2012 Rule 17.7:
> "... If the return value of a function is intended not to be used
> explicitly, it should be cast to the void type. ..."
>
> It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #75 from Zdenek Sojka ---
(In reply to Florian Weimer from comment #74)
> (In reply to Zdenek Sojka from comment #73)
> > See MISRA C:2012 Rule 17.7:
> > "... If the return value of a function is intended not to be used
> > explicitl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #76 from Jakub Jelinek ---
(void) casts not quieting the warning was an intentional request when the
warning has been added, I really don't think it is a good idea to change that.
The fact that clang people can't properly implement Pe
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 #78 from Segher Boessenkool ---
(In reply to Andrew Church from comment #77)
> (In reply to Segher Boessenkool from comment #72)
> > if (foo()) {
> > /* The return value of foo can be ignored here because X and Y. */
> > }
>
> Thi
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 #80 from Segher Boessenkool ---
(In reply to Andrew Church from comment #79)
> (In reply to Segher Boessenkool from comment #78)
> > If someone (the user, the author, anyone) used warn_unused_result where it
> > is
> > not appropriat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #81 from rusty at rustcorp dot com.au ---
(In reply to Jakub Jelinek from comment #76)
> (void) casts not quieting the warning was an intentional request when the
> warning has been added, I really don't think it is a good idea to chan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #82 from Segher Boessenkool ---
(In reply to rusty from comment #81)
> Not many function returns are as clearly required as realloc...
Then they shouldn't use warn_unused_result! The documentation of that is
very very clear: both ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #83 from rusty at rustcorp dot com.au ---
> Then they shouldn't use warn_unused_result! The documentation of that is
> very very clear: both about what it does, and about what situations it is
> meant for. People who want something
83 matches
Mail list logo
