Re: Request for suppressing "warn_unused_result" warnings
On 05/28/2010 06:36 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
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,
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
RE: Request for suppressing "warn_unused_result" warnings
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:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini
Sent: Friday, May 28, 2010 9:12 AM
To: Lavrentiev, Anton (NIH/NLM/NCBI) [C]
Cc: gcc@gcc.gnu.org; Vakatov, Denis (NIH/NLM/NCBI) [E]
Subject: Re: Request for suppressing "warn_unused_result" warnings
On 05/28/2010 06:36 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> 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,
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
Re: Request for suppressing "warn_unused_result" warnings
On Fri, May 28, 2010 at 18:12, Vakatov, Denis (NIH/NLM/NCBI) [E] wrote: > 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
RE: Request for suppressing "warn_unused_result" warnings
> 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. > 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: paolo.bonz...@gmail.com [mailto:paolo.bonz...@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@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] wrote: > 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
Re: Request for suppressing "warn_unused_result" warnings
"Vakatov, Denis (NIH/NLM/NCBI) [E]" writes: > 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
RE: Request for suppressing "warn_unused_result" warnings
Ian Lance Taylor wrote: > 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
Re: Request for suppressing "warn_unused_result" warnings
"Vakatov, Denis (NIH/NLM/NCBI) [E]" writes: > Ian Lance Taylor wrote: > >> 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. > 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
Re: Request for suppressing "warn_unused_result" warnings
On Fri, May 28, 2010 at 11:25 PM, Ian Lance Taylor wrote: > "Vakatov, Denis (NIH/NLM/NCBI) [E]" writes: > >> Ian Lance Taylor wrote: >> >>> 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. > > >> 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.
RE: Request for suppressing "warn_unused_result" warnings
Ian Lance Taylor wrote: > [...] 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
Re: Request for suppressing "warn_unused_result" warnings
"Vakatov, Denis (NIH/NLM/NCBI) [E]" writes: > 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
Re: Request for suppressing "warn_unused_result" warnings
On 28/05/2010 19:32, Ian Lance Taylor wrote: > 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". > 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
Re: Request for suppressing "warn_unused_result" warnings
On 28/05/2010 22:25, Ian Lance Taylor wrote:
> "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.
> 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.
> 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.
> 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
the attitude that Paolo's original proposed workaround:
>
> 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.
... is in fact a bug that should be fixed. The return result from the
function is still ignored, after all.
cheers,
DaveK
Re: Request for suppressing "warn_unused_result" warnings
Dave Korn writes: > On 28/05/2010 19:32, Ian Lance Taylor wrote: > >> 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". > >> 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
Re: Request for suppressing "warn_unused_result" warnings
Dave Korn writes: > On 28/05/2010 22:25, Ian Lance Taylor wrote: > >> 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. > >> 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
Re: Request for suppressing "warn_unused_result" warnings
On 29/05/2010 01:17, Ian Lance Taylor wrote: > Dave Korn writes: > >> On 28/05/2010 22:25, Ian Lance Taylor wrote: >> >>> 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. >> >>> 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
Re: Request for suppressing "warn_unused_result" warnings
On 29/05/2010 01:14, Ian Lance Taylor wrote: > 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! > 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
Re: Request for suppressing "warn_unused_result" warnings
Dave Korn writes: > On 29/05/2010 01:14, Ian Lance Taylor wrote: >> 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. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Request for suppressing "warn_unused_result" warnings
On Sat, May 29, 2010 at 3:13 AM, Dave Korn wrote: > On 29/05/2010 01:17, Ian Lance Taylor wrote: >> Dave Korn writes: >> >>> On 28/05/2010 22:25, Ian Lance Taylor wrote: >>> 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. >>> 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 > > >
Re: Request for suppressing "warn_unused_result" warnings
On Sat, May 29, 2010 at 3:16 AM, Dave Korn wrote: > On 29/05/2010 01:14, Ian Lance Taylor wrote: >> 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! > >> 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 > > >
Re: Request for suppressing "warn_unused_result" warnings
On 29/05/2010 11:55, Richard Guenther wrote: > On Sat, May 29, 2010 at 3:16 AM, Dave Korn wrote: >> 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
Re: Request for suppressing "warn_unused_result" warnings
On Fri, May 28, 2010 at 11:32:46AM -0700, Ian Lance Taylor wrote:
> 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.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
RE: Request for suppressing "warn_unused_result" warnings
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
