Request for suppressing "warn_unused_result" warnings

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

Dear GCC developers,

Would you please consider suppressing (relatively new) warnings like this one:

ignoring return value of 'int chdir(const char*)', declared with attribute warn_unused_result

in cases when the source code explicitly casts the result to (void). Like in

(void) chdir("/");

There is no check necessary in this rare case, yet the compiler seems to ignore the
explicit cast (which tells the developer's intention exactly: there is nothing to check),
and keeps issuing the warning, regardless.

Making dummy assignment and/or check around such a chdir call (just to satisfy the
"unused result" requirement) will not help make the code any cleaner.

There are always a subtle number of cases for almost any "__wur" call that do not
need any result consumption. Yet the warning in general is very helpful in
catching the situation where the result is not consumed *explicitly*.

We're lagging behind the GCC development here and perhaps the newest version of the
compiler does already implement this suggestion -- so let me apologize for the noise then.

Thanks for considering this suggestion,

Anton Lavrentiev
Contractor NIH/NLM/NCBI

[Paolo Bonzini]

Post by Lavrentiev, Anton (NIH/NLM/NCBI) [C]
Dear GCC developers,
ignoring return value of 'int chdir(const char*)', declared with
attribute warn_unused_result
in cases when the source code explicitly casts the result to (void).
Like in
(void) chdir("/");
There is no check necessary in this rare case, yet the compiler
seems to ignore the explicit cast (which tells the developer's
intention exactly: there is nothing to check), and keeps issuing the
warning, regardless.
Making dummy assignment and/or check around such a chdir call (just
to satisfy the "unused result" requirement) will not help make the
code any cleaner.
There are always a subtle number of cases for almost any "__wur"
call that do not need any result consumption. Yet the warning in
general is very helpful in catching the situation where the result is
not consumed *explicitly*.
We're lagging behind the GCC development here and perhaps the newest
version of the compiler does already implement this suggestion -- so
let me apologize for the noise then.
Thanks for considering this suggestion,

Bugzilla unfortunately has a lot of discussion about this issue, and the
outcome was that the feature was done this way by design.

What you reported is not the only common intended violation of __wur.
It is for example possible to ignore the result of fwrite and defer
error checking to fflush or fclose, but __wur does not help with this
style.

I suggest that you add two functions like these:

static inline void ignore_value (int i) { (void) i; }
static inline void ignore_ptr (void* p) { (void) p; }

that you can use instead of the (void) cast.

Nevertheless, thanks for writing your report in a very polite way, which
didn't occur in some of the previous cases.

Paolo

[Vakatov, Denis (NIH/NLM/NCBI) [E]]

Hi Paolo,

Can this design please be changed (or, dare I say without being considered impolite, improved) to better accommodate for the cases where there is indeed no reason for checking the return value?

Making the developers jump through more complicated ad hoc hoops (instead of just void-casting the func call) requires "too much" effort, and regular developers usually won't do it. So, this will increase the "warning noise", which will desensitize the developers, and make them pay less attention to really useful warnings. Cases like this therefore make the whole GCC warning mechanism less effective, and it diminishes the great effort that you GCC developers put into helping developers write cleaner code.

Please make it simpler for the developers to write warning-free code!

Thanks,
Denis



-----Original Message-----
From: Paolo Bonzini [mailto:***@gmail.com] On Behalf Of Paolo Bonzini
Sent: Friday, May 28, 2010 9:12 AM
To: Lavrentiev, Anton (NIH/NLM/NCBI) [C]
Cc: ***@gcc.gnu.org; Vakatov, Denis (NIH/NLM/NCBI) [E]
Subject: Re: Request for suppressing "warn_unused_result" warnings

Post by Lavrentiev, Anton (NIH/NLM/NCBI) [C]
Dear GCC developers,
ignoring return value of 'int chdir(const char*)', declared with
attribute warn_unused_result
in cases when the source code explicitly casts the result to (void).
Like in
(void) chdir("/");
There is no check necessary in this rare case, yet the compiler
seems to ignore the explicit cast (which tells the developer's
intention exactly: there is nothing to check), and keeps issuing the
warning, regardless.
Making dummy assignment and/or check around such a chdir call (just
to satisfy the "unused result" requirement) will not help make the
code any cleaner.
There are always a subtle number of cases for almost any "__wur"
call that do not need any result consumption. Yet the warning in
general is very helpful in catching the situation where the result is
not consumed *explicitly*.
We're lagging behind the GCC development here and perhaps the newest
version of the compiler does already implement this suggestion -- so
let me apologize for the noise then.
Thanks for considering this suggestion,

Bugzilla unfortunately has a lot of discussion about this issue, and the
outcome was that the feature was done this way by design.

What you reported is not the only common intended violation of __wur.
It is for example possible to ignore the result of fwrite and defer
error checking to fflush or fclose, but __wur does not help with this
style.

I suggest that you add two functions like these:

static inline void ignore_value (int i) { (void) i; }
static inline void ignore_ptr (void* p) { (void) p; }

that you can use instead of the (void) cast.

Nevertheless, thanks for writing your report in a very polite way, which
didn't occur in some of the previous cases.

Paolo

[Paolo Bonzini]

On Fri, May 28, 2010 at 18:12, Vakatov, Denis (NIH/NLM/NCBI) [E]

Post by Vakatov, Denis (NIH/NLM/NCBI) [E]
Hi Paolo,
Can this design please be changed

By saying "by design" I was implying that it won't.

FWIW I agree with you, but I'm also very undecided whether it is not
glibc that was too greedy in applying __wur (which also won't be
changed BTW).

Paolo

[Vakatov, Denis (NIH/NLM/NCBI) [E]]

Post by Paolo Bonzini
By saying "by design" I was implying that it won't.

-- It's like saying "by divine design" then. Because, human-made designs usually can -- and oftentimes should -- be changed :-).

Just think about it. All these little caveats work *against* the main cause, and they accumulate with time.

Post by Paolo Bonzini
I'm also very undecided whether it is not glibc that was too greedy in applying __wur (which also won't be changed BTW).

-- At least in what I see in our code, the application of __wur looked rather reasonable. And, if you do allow the developers to easily handle any overreach in the application of __wur (by merely "voiding" the func call)... that will greatly diminish the adverse effect of the __wur overreachments.


Thanks,
Denis


-----Original Message-----
From: ***@gmail.com [mailto:***@gmail.com] On Behalf Of Paolo Bonzini
Sent: Friday, May 28, 2010 1:10 PM
To: Vakatov, Denis (NIH/NLM/NCBI) [E]
Cc: Lavrentiev, Anton (NIH/NLM/NCBI) [C]; ***@gcc.gnu.org
Subject: Re: Request for suppressing "warn_unused_result" warnings

On Fri, May 28, 2010 at 18:12, Vakatov, Denis (NIH/NLM/NCBI) [E]

Post by Paolo Bonzini
Hi Paolo,
Can this design please be changed

By saying "by design" I was implying that it won't.

FWIW I agree with you, but I'm also very undecided whether it is not
glibc that was too greedy in applying __wur (which also won't be
changed BTW).

Paolo

[Ian Lance Taylor]

Post by Vakatov, Denis (NIH/NLM/NCBI) [E]
Can this design please be changed (or, dare I say without being
considered impolite, improved) to better accommodate for the cases
where there is indeed no reason for checking the return value?
Making the developers jump through more complicated ad hoc hoops
(instead of just void-casting the func call) requires "too much"
effort, and regular developers usually won't do it. So, this will
increase the "warning noise", which will desensitize the developers,
and make them pay less attention to really useful warnings. Cases
like this therefore make the whole GCC warning mechanism less
effective, and it diminishes the great effort that you GCC
developers put into helping developers write cleaner code.

Please don't top-post.

Please read http://gcc.gnu.org/PR25509 .

As the compiler documentation states, warn_unused_result was intended
for cases where failing to check the return value is always a security
risk or a bug. The documentation cites the example of realloc. That
is a case where casting the return value to (void) would always be
wrong. The compiler really should warn for that code by default; if
you have some crazy need to ignore the result of realloc, just use the
-Wno-unused-result option.

That said, I agree that glibc is overly aggressive in using
warn_unused_result when FORTIFY_SOURCE is defined. I agree that
Debian is overly aggressive in having a distro-specific patch to
enable FORTIFY_SOURCE by default. I think that both of those
decisions were ill-advised. The combination of those decisions with
the ones made by the gcc developers definitely makes some code
inappropriately awkward.

So what are the right choices here? I tend to be reluctant to endorse
adding a new option, but I can't think of another approach. I think
we should consider introducing a new gcc function attribute:
must_use_result. I think we should document that attribute as
intended specifically for cases where failing to use the return value
is a program error, as with calls to realloc. We should handle
must_use_result and warn_unused_result similarly, except that adding a
cast to (void) disables the warn_unused_result warning. Perhaps there
should also be other simple ways to disable the warn_unused_result
warning.

This is not a great solution, but I don't see a better way out of the
current unpleasant situation.

Ian

[Vakatov, Denis (NIH/NLM/NCBI) [E]]

We should handle must_use_result and warn_unused_result similarly, except that adding a cast to (void) disables the warn_unused_result warning. Perhaps there should also be other simple ways to disable the warn_unused_result warning.
This is not a great solution, but I don't see a better way out of the current unpleasant situation.

You seem to be looking for an absolute solution, and there is none. You can't do it all on the GCC side alone.

The reasonable (or, "great enough") solution would be to just trust explicit developer's void-casting.

Also, 'warn_unused_result' should be enough; there is no need to add more levels to this simple paradigm.

Denis

[Ian Lance Taylor]

Post by Vakatov, Denis (NIH/NLM/NCBI) [E]

We should handle must_use_result and warn_unused_result similarly, except that adding a cast to (void) disables the warn_unused_result warning. Perhaps there should also be other simple ways to disable the warn_unused_result warning.
This is not a great solution, but I don't see a better way out of the current unpleasant situation.

You seem to be looking for an absolute solution, and there is
none. You can't do it all on the GCC side alone.

Yes, of course. That was implicit in my suggestion.

Post by Vakatov, Denis (NIH/NLM/NCBI) [E]
The reasonable (or, "great enough") solution would be to just trust
explicit developer's void-casting.
Also, 'warn_unused_result' should be enough; there is no need to add
more levels to this simple paradigm.

The warn_unused_result extension was implemented specifically to catch
security problems. Permitting developers to just add a cast to void
would make it a very weak facility. Of course in one sense we should
trust the developer. But the history of security problems shows that
developers can not always be trusted. Instead, we assume that there
at least one trusted developer who can add warn_unused_result when
appropriate. Then the compiler arranges matters such that other
developers can not easily avoid the warning. Thus security is,
ideally, increased.

Unfortunately this hasn't worked in practice, because glibc and Debian
have combined to make many reasonable compilations, which have no
security issues, run afoul of warn_unused_result. So my proposal is
to change the existing facility to make it be what glibc and Debian
really want, and to provide a new facility which does what
warn_unused_result was originally intended to do.

I would interpret your suggestion as being that we should abandon the
security goals of warn_unused_result, and settle for the weaker
version which glibc and Debian seem to want. Perhaps that is the
correct way to go. But it does not seem so to me.

Ian

[Richard Guenther]

Post by Vakatov, Denis (NIH/NLM/NCBI) [E]

We should handle must_use_result and warn_unused_result similarly, except that adding a cast to (void) disables the warn_unused_result warning.  Perhaps there should also be other simple ways to disable the warn_unused_result warning.
This is not a great solution, but I don't see a better way out of the current unpleasant situation.

You seem to be looking for an absolute solution, and there is
none. You can't do it all on the GCC side alone.

Yes, of course.  That was implicit in my suggestion.

Post by Vakatov, Denis (NIH/NLM/NCBI) [E]
The reasonable (or, "great enough") solution would be to just trust
explicit developer's void-casting.
Also, 'warn_unused_result' should be enough; there is no need to add
more levels to this simple paradigm.

The warn_unused_result extension was implemented specifically to catch
security problems.  Permitting developers to just add a cast to void
would make it a very weak facility.  Of course in one sense we should
trust the developer.  But the history of security problems shows that
developers can not always be trusted.  Instead, we assume that there
at least one trusted developer who can add warn_unused_result when
appropriate.  Then the compiler arranges matters such that other
developers can not easily avoid the warning.  Thus security is,
ideally, increased.
Unfortunately this hasn't worked in practice, because glibc and Debian
have combined to make many reasonable compilations, which have no
security issues, run afoul of warn_unused_result.  So my proposal is
to change the existing facility to make it be what glibc and Debian
really want, and to provide a new facility which does what
warn_unused_result was originally intended to do.
I would interpret your suggestion as being that we should abandon the
security goals of warn_unused_result, and settle for the weaker
version which glibc and Debian seem to want.  Perhaps that is the
correct way to go.  But it does not seem so to me.

I think we should simply stay with what we have. glibc should change
(and vendors can just patch it if glibc upstream remains unreasonable
on the issue).

GCC is certainly the wrong side for a fix.

Richard.

[Vakatov, Denis (NIH/NLM/NCBI) [E]]

[...] developers can not always be trusted. Instead, we assume that there at least one trusted developer who can add warn_unused_result when
appropriate. Then the compiler arranges matters such that other developers can not easily avoid the warning. Thus security is, ideally, increased.
I would interpret your suggestion as being that we should abandon the security goals of warn_unused_result, and settle for the weaker version which glibc and Debian seem to want. Perhaps that is the correct way to go. But it does not seem so to me.

The problem with the suggested scenario with one trusted developer that uses this option is that other developers won't see these warnings at all. However, IMO we can have our cake and eat it too -- and, leave most of the involved parties generally happy...er. Say, we allow the void-casting to suppress the warning but we have yet another compilation flag (or macro) which the trusted developer can turn on to get warnings on the void-casted calls too.

This way, regular developers can suppress the warning where they believe it should be suppressed while the code reviewer still can see all such suppressed warnings. So, the regular developers will be able to see the warnings -- and either fix or easily suppress them. And the security (provided by the code reviewer armed with that other flag/macro) won't be compromised.


Denis

[Ian Lance Taylor]

Post by Vakatov, Denis (NIH/NLM/NCBI) [E]
The problem with the suggested scenario with one trusted developer
that uses this option is that other developers won't see these
warnings at all. However, IMO we can have our cake and eat it too --
and, leave most of the involved parties generally happy...er. Say,
we allow the void-casting to suppress the warning but we have yet
another compilation flag (or macro) which the trusted developer can
turn on to get warnings on the void-casted calls too.
This way, regular developers can suppress the warning where they
believe it should be suppressed while the code reviewer still can
see all such suppressed warnings. So, the regular developers will be
able to see the warnings -- and either fix or easily suppress
them. And the security (provided by the code reviewer armed with
that other flag/macro) won't be compromised.

Sure, yet another compiler option is also another way to go. I do not
happen to think that is the best approach in this case.

I think you may have misunderstood my scenario. I was not suggesting
that the trusted developer use a special option. I was suggesting
that the trusted developer add the warn_unused_result or
must_use_result function attribute. I don't think a scenario which
relies on somebody recompiling all code with a different option is
appropriate for avoiding security issues.

Ian

[Dave Korn]

Post by Ian Lance Taylor

Post by Vakatov, Denis (NIH/NLM/NCBI) [E]
The reasonable (or, "great enough") solution would be to just trust
explicit developer's void-casting.
Also, 'warn_unused_result' should be enough; there is no need to add
more levels to this simple paradigm.

The warn_unused_result extension was implemented specifically to catch
security problems. Permitting developers to just add a cast to void
would make it a very weak facility.

But it's a weak and fundamentally flawed facility in the first place.
Permitting people to *believe* they can rely on it would be just as bad as
permitting explicit loopholes.

Post by Ian Lance Taylor
the history of security problems shows that
developers can not always be trusted.

Yeh, but it also shows just as surely that dumb-minded static analysis isn't
any use at all.

Post by Ian Lance Taylor
So my proposal is
to change the existing facility to make it be what glibc and Debian
really want, and to provide a new facility which does what
warn_unused_result was originally intended to do.

My proposal is that we acknowledge that we have two different classes of
users here, whose interests are different, and that we don't take sides in any
conflict between them.

Post by Ian Lance Taylor
abandon the
security goals of warn_unused_result

I honestly don't believe it has any (achievable) security goals. I don't
see how it's any more useful than grepping for 'strcpy' and saying 'Hey that
could be a bug'.

Also, if anyone wants to stand by this at all, then they are obliged to take

Post by Ian Lance Taylor
static inline void ignore_value (int i) { (void) i; }
static inline void ignore_ptr (void* p) { (void) p; }
that you can use instead of the (void) cast.

... is in fact a bug that should be fixed. The return result from the
function is still ignored, after all.

cheers,
DaveK

[Ian Lance Taylor]

Post by Dave Korn

Post by Ian Lance Taylor
The warn_unused_result extension was implemented specifically to catch
security problems. Permitting developers to just add a cast to void
would make it a very weak facility.

But it's a weak and fundamentally flawed facility in the first place.
Permitting people to *believe* they can rely on it would be just as bad as
permitting explicit loopholes.

Post by Ian Lance Taylor
the history of security problems shows that
developers can not always be trusted.

Yeh, but it also shows just as surely that dumb-minded static analysis isn't
any use at all.

These statements are too strong. Of course programmers can outwit any
such techniques. But these techniques can still catch real accidental
mistakes. It's simply false to say that dumb-minded static analysis
isn't any use at all. E.g., identifying and removing calls to the
standard gets function is a simple and completely appropriate
technique for increasing security. Simple static analysis doesn't
solve all problems, but it does not follow that it isn't any use.

Ian

[Dave Korn]

Post by Ian Lance Taylor

Post by Dave Korn

Post by Ian Lance Taylor
The warn_unused_result extension was implemented specifically to catch
security problems. Permitting developers to just add a cast to void
would make it a very weak facility.

But it's a weak and fundamentally flawed facility in the first place.
Permitting people to *believe* they can rely on it would be just as bad as
permitting explicit loopholes.

Post by Ian Lance Taylor
the history of security problems shows that
developers can not always be trusted.

Yeh, but it also shows just as surely that dumb-minded static analysis isn't
any use at all.

These statements are too strong. Of course programmers can outwit any
such techniques. But these techniques can still catch real accidental
mistakes. It's simply false to say that dumb-minded static analysis
isn't any use at all. E.g., identifying and removing calls to the
standard gets function is a simple and completely appropriate
technique for increasing security. Simple static analysis doesn't
solve all problems, but it does not follow that it isn't any use.

Yes, of course that's true, I was certainly being hyperbolic for effect :)
But doesn't that really argue that there should always be an override
mechanism? I think we're straying from compiler-warning into lint territory here.

cheers,
DaveK

[Richard Guenther]

Post by Ian Lance Taylor
The warn_unused_result extension was implemented specifically to catch
security problems.  Permitting developers to just add a cast to void
would make it a very weak facility.

  But it's a weak and fundamentally flawed facility in the first place.
Permitting people to *believe* they can rely on it would be just as bad as
permitting explicit loopholes.

Post by Ian Lance Taylor
the history of security problems shows that
developers can not always be trusted.

  Yeh, but it also shows just as surely that dumb-minded static analysis isn't
any use at all.

These statements are too strong.  Of course programmers can outwit any
such techniques.  But these techniques can still catch real accidental
mistakes.  It's simply false to say that dumb-minded static analysis
isn't any use at all.  E.g., identifying and removing calls to the
standard gets function is a simple and completely appropriate
technique for increasing security.  Simple static analysis doesn't
solve all problems, but it does not follow that it isn't any use.

 Yes, of course that's true, I was certainly being hyperbolic for effect :)
But doesn't that really argue that there should always be an override
mechanism?  I think we're straying from compiler-warning into lint territory here.

No, we only provide means to mark functions in a way and unconditionally
warn. We can't control how the attribute is used and the attribute was
_designed_ to be non-overridable. We shouldn't change semantics of
an attribute.

Similar issues exist with the nonnull attribute, which when not carefully
used will even result in miscompilations, not only false warnings. And
we've repeatedly closed bugreports about this as invalid. So should
we do for invalid or inappropriate users of warn_unused_return.

Richard.

   cheers,
     DaveK

[Dave Korn]

Post by Ian Lance Taylor
As the compiler documentation states, warn_unused_result was intended
for cases where failing to check the return value is always a security

^^^^^^
Note: "always".

Post by Ian Lance Taylor
risk or a bug.

OK, that's reasonable as far as it goes, but there is *no* circumstances
under which ignoring the return from *any* function is *always* a bug. So we
should provide a user override mechanism.

I read the whole PR22509 audit trail, and it seems to me the reasoning is
based on a false assumption that there is only one set of consumers of GCC,
and that is "everybody". I'm willing to believe that there are two classes of
users, those who build OSes and system libcs, and those who just want to write
end-user code; and that their interests might sometimes be in conflict, and
therefore the compiler shouldn't enforce the standards of either one of our
subset of users against the others.

cheers,
DaveK

[Ian Lance Taylor]

Post by Dave Korn

Post by Ian Lance Taylor
As the compiler documentation states, warn_unused_result was intended
for cases where failing to check the return value is always a security

^^^^^^
Note: "always".

Post by Ian Lance Taylor
risk or a bug.

OK, that's reasonable as far as it goes, but there is *no* circumstances
under which ignoring the return from *any* function is *always* a bug. So we
should provide a user override mechanism.

For practical purposes, it is always a bug to ignore the return value
of realloc (I disregard the unusual case of passing 0 as the second
argument in order to free the memory block). The original patch
description (http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00798.html)
said there are calls in the Linux kernel whose return value must never
be ignored. So I assert that there are such cases.

We could certainly decide that we don't care about that fine
distinction, and just fall back to the weaker definition which permits
easy overriding with a cast to void. But we shouldn't do it on the
basis that the current definition does not make sense. We should only
do it on the basis that the current definition is not worth
preserving.

Ian

[Dave Korn]

Post by Ian Lance Taylor

Post by Dave Korn
there is *no* circumstances
under which ignoring the return from *any* function is *always* a bug.

For practical purposes, it is always a bug to ignore the return value
of realloc (I disregard the unusual case of passing 0 as the second
argument in order to free the memory block).

Also the case of calling it for a size that is known a priori to be less
than the original size of the block!

Post by Ian Lance Taylor
We could certainly decide that we don't care about that fine
distinction, and just fall back to the weaker definition which permits
easy overriding with a cast to void. But we shouldn't do it on the
basis that the current definition does not make sense. We should only
do it on the basis that the current definition is not worth
preserving.

I guess that's what I'm having a hard time being convinced of. It seems to
me that for most of the warnings we provide, we have a mechanism to allow
users to disregard them in system headers.

What it really is is, I don't see the consistency in disregarding an
explicit cast to void, yet permitting a workaround such as an inlined no-op
function that casts the parameter to void. Isn't that just a bug, that it
fools the warning, and it ought to be fixed?

cheers,
DaveK

[Andreas Schwab]

Post by Dave Korn

Post by Ian Lance Taylor

Post by Dave Korn
there is *no* circumstances
under which ignoring the return from *any* function is *always* a bug.

For practical purposes, it is always a bug to ignore the return value
of realloc (I disregard the unusual case of passing 0 as the second
argument in order to free the memory block).

Also the case of calling it for a size that is known a priori to be less
than the original size of the block!

Depending on the implementation it may be necessary to relocate the
block even in this case.

Andreas.

[Richard Guenther]

Post by Ian Lance Taylor

  there is *no* circumstances
under which ignoring the return from *any* function is *always* a bug.

For practical purposes, it is always a bug to ignore the return value
of realloc (I disregard the unusual case of passing 0 as the second
argument in order to free the memory block).

 Also the case of calling it for a size that is known a priori to be less
than the original size of the block!

Post by Ian Lance Taylor
We could certainly decide that we don't care about that fine
distinction, and just fall back to the weaker definition which permits
easy overriding with a cast to void.  But we shouldn't do it on the
basis that the current definition does not make sense.  We should only
do it on the basis that the current definition is not worth
preserving.

 I guess that's what I'm having a hard time being convinced of.  It seems to
me that for most of the warnings we provide, we have a mechanism to allow
users to disregard them in system headers.
 What it really is is, I don't see the consistency in disregarding an
explicit cast to void, yet permitting a workaround such as an inlined no-op
function that casts the parameter to void.  Isn't that just a bug, that it
fools the warning, and it ought to be fixed?

Yes. Please file a bugreport (and first check the proposed workaround
really works..).

Richard.

   cheers,
     DaveK

[Dave Korn]

Post by Richard Guenther

Post by Dave Korn
What it really is is, I don't see the consistency in disregarding an
explicit cast to void, yet permitting a workaround such as an inlined no-op
function that casts the parameter to void. Isn't that just a bug, that it
fools the warning, and it ought to be fixed?

Yes. Please file a bugreport (and first check the proposed workaround
really works..).

It does. PR44321.

cheers,
DaveK

[Vakatov, Denis (NIH/NLM/NCBI) [E]]

Okay, I guess we 'll just disable the __wur's by default then -- as introducing an unnecessary hard-to-avoid noise. I recon many other people do the same.

Thanks nevertheless. It's still a useful feature, just not flexible enough to use it for *everyday* compilation.

Denis

[Basile Starynkevitch]

Post by Ian Lance Taylor
Please read http://gcc.gnu.org/PR25509 .
As the compiler documentation states, warn_unused_result was intended
for cases where failing to check the return value is always a security
risk or a bug. The documentation cites the example of realloc. That
is a case where casting the return value to (void) would always be
wrong. The compiler really should warn for that code by default; if
you have some crazy need to ignore the result of realloc, just use the
-Wno-unused-result option.
That said, I agree that glibc is overly aggressive in using
warn_unused_result when FORTIFY_SOURCE is defined. I agree that
Debian is overly aggressive in having a distro-specific patch to
enable FORTIFY_SOURCE by default. I think that both of those
decisions were ill-advised. The combination of those decisions with
the ones made by the gcc developers definitely makes some code
inappropriately awkward.
So what are the right choices here? I tend to be reluctant to endorse
adding a new option, but I can't think of another approach.

Perhaps we might have a pragma to avoid a specific occurrence of the warning.

So the example code would become:

extern int foo() __attribute__((warn_unused_result));
int main()
{
/* the pragma has effect only on the following statement */
#pragma GCC dont_warn_unused_result
(void) foo();

return 0;
}

Or perhaps even
_Pragma(GCC(dont_warn_unused_result), foo())

I know that pragmas have been undesirable in GCC, but perhaps in that
case (marking a specific occurrence or statement) they might be
ok. AFAIK, we don't have statement attributes.

Or perhaps it should be yet another builtin, eg
builtin_dont_warn_unused_result(foo())

An artificial, contrieved, hypothetical use case could be when the
programmer know for sure that a particular call occurrence to a
warn_unused_result function don't return normally (e.g. always throws
a C++ exception or do a setjmp in C or loop forever.).

But I agree that all this is not very important. Sorry for bothering!

Regards.