On 11 Jan 2007 17:29:10 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> On 11 Jan 2007 15:48:36 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> > > * A function can return either with or without a value.
> >
> > I give up.
>
> :-) None said it was going to be easy. We have a warning similar to this:
>
> -Wreturn-type
> warn about any "return" statement with no return-value in a
> function whose return-type is not "void".
>
> However, this is enabled by Wall and the one from Wextra surely
> produces false positives (I guess that is the reason it is in Wextra).
> -Wreturn-type-may ?
I tend to think that having some returns with a value and some without
is an error. Maybe grouping them in -Wreturn-type makes sense,
although the name is not quite right.
Behold! The example in the manual is:
foo (a)
{
if (a > 0)
return a;
}
But actually this doesn't fly: there is no special warning with
-Wextra, and -Wreturn-type says "control reaches end of non-void
function"
So I tried another testcase from the testsuite of Wextra:
int bar (void)
{
if( i ) return;
else return 1;
} /* { dg-warning "may return with or without a value" } */
But this is warned already by Wreturn-type: "'return' with no value,
in function returning non-void".
I wasn't able to come up with a testcase that is warned by Wextra but
not by Wreturn-type.
I vote for removal if nobody can come up with a testcase.
> > > * An unsigned value is compared against zero with < or >=.
> > > Walways-true claims to warn for this but it doesn't. There is also an
> > > unconditional warning for expressions that are always true or false
> > > due to the range of types.
> >
> > -Walways-true should warn for this.
>
> No, I think it shouldn't but let's leave this for now, please. I need
> to do a bit more of research and archive archaeology to properly
> justify why I think that this is a Really Bad Idea (TM). Or we could
> just drop the idea @ kernel.org and see what happens. Any brave
> volunteer?
-Wunsigned-compare?
See http://gcc.gnu.org/ml/gcc/2007-01/msg00480.html for why not Walways-true.
We have another warning for comparisons that are always true due to
the range of data types. We even have a PR about this inconsistency.
(see PR23587). Thus, Wunsigned-compare is not an apt name.
Joseph Myers proposed Wcomparison-fixed a very long time ago, so I
made a patch for it
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01120.html but I need
help to come up with portable testcases.
Thanks.
Manuel.
