Re: Bug#119440: g++: Compiler does not give any errors when a function fails to return required value
On Wed, 14 Nov 2001, Eray Ozkural (exa) wrote:
> Are you a g++ author?
I am, although not on a regular basis (I write in ANSI C much more).
> This illustrates what I'm exactly talking about. IIRC some other compilers
> will complain about the f function not returning any value here. (Have to
> check, though)
Please do. I'd be curious what compiler, given no warning options,
catches this situation. I can't think of one, personally, but I'm
definitely not saying that there aren't any.
> The problem with the above code is that g++ will compile the code as if it is
> normal, and when you run it, it will just spew out a random result.
It's not really spewing out a random result; it's outputting the contents
of the memory space for the return value of f(), which is exactly what it
should do. Granted, it would be nice if the compiler cleared that space
or assigned it to null when the function is initially called, but it's not
necessary according to the standard, IIRC.
> g++ compiles this code without giving any warnings by default. However, as
> you can see the f(..) function lacks a return statement. It's also evident
> that there cannot be any exit or throw out of the function. If there isn't a
> single control path that contains a return statement, you can't expect the
> function to ever return anything, it is a programming error. exit or throw
> would be employed in a function only in the case of exceptions, so if a
> function has a non void return type but only serves to exit or throw
> exception (like your example) that is also precisely a programming error. It
> might be valid in C++ specification (is it?), but the compiler should warn
> about it.
I believe it's valid, although I'd have to check the standard in question
to be sure.
> I would think that the compiler should give a warning by default in this
> case, otherwise it is misleading to the programmer who is accustomed to the
> "typesafety" of the language.
How is this behaviour misleading in relation to type safety? I don't
understand the rationale.
> In other words, "-Wreturn-type" does not seem to solve this problem. The
> compiler would have to detect whether there is no path that returns a value
> rather than detecting whether there is a path that does not return a value to
> give a useful warning message.
I believe that both behaviours are synonymous in this case. Is there a
case where -Wreturn-type doesn't catch the lack of a return statement in a
function that is declared as non-void? The example that you provided does
trigger a warning with -Wreturn-type.
My take on this discussion is that you want there to be a warning by
default to catch sloppy (but valid) programming (no offence, that's just
my take on it). I believe that Martin and the others are saying that
-Wreturn-type catches this specific problem, but that it is not the
default behaviour because the code is still valid (although the outcome
may not be what the programmer desired). Am I correct? If so, then I
agree with Martin. By default, g++ should catch problems that may cause
critical operational issues, like non-cast assignments to a different
type, etc, not just catch the "you may not like what you get" cases
that happen to be valid. For the latter, a ton of -W options are there
for the picking (some of which aren't even enabled by -Wall, btw).
C
Reply to: