Gnu Cpp - missing error message on missing return statement

[White-Gandalf]

Hallo,

i stumbled over a curious behavior today, which i never saw in more than 15 years of usage of cpp compilers:

The following gets compiled without any error message by gpp 3.4.5 (from mingw, included in devcpp), where i normally would seriously expect an error message:

sometype funcname(sometype somearg)
{
    do_something(somearg);
    // NO RETURN-STATEMENT!
}

From Borland/MS/Watcom i have never seen such a thing possible: I had always have to do compiler specific stuff if i wanted - for any good reason like assembler inlines - such things to be compilable.

Ho is this to be interpreted? Is that a new feature from Ansi99?
Or is this a bug?
Or is this dependend from some special build-in features? And overridable on the command line?

[White-Gandalf]

Solved adding command line option "-W -Wall -pedantic"

[VernonDozier]

I ran this program in Dev C++ and got the same non-error:

#include <iostream>
using namespace std;

int foo (int a);
void do_something (int a);

int main ()
{
    int a = 5;
    int b = 10;
    b = foo (a);
    cout << "In main post call: a = " << a << endl;
    cout << "In main post call: b = " << b << endl;    
    return 0;
}


int foo (int a)
{
    cout << "In foo before call: a = " << a << endl;
    do_something (a);
    cout << "In foo post call: a = " << a << endl;  
}


void do_something (int a)
{
     cout << "In do_something: a = " << a << endl;
}

Here were my results:

In foo before call: a = 5
In do_something: a = 5
In foo post call: a = 5
In main post call: a = 5
In main post call: b = 4469696

The a values seem to pass as one would expect and not change. It shouldn't compile as far as I can tell and it returns a jibberish integer apparently. Strange.

[VernonDozier]

Solved adding command line option "-W -Wall -pedantic"

I ran the program in Dev C++ adding the above compiler option. It gave me a warning:

G:\Documents and Settings\Joe\Desktop\trialprograms\dummy.cpp In function `int foo(int)':
24 G:\Documents and Settings\Joe\Desktop\trialprograms\dummy.cpp [Warning] control reaches end of non-void function

but it still compiled and ran with the same results, only I got the warning.

[White-Gandalf]

Well, yes, a similar problem arose on a support session today. A newbe had simply programmed around the arguments interface on the bases of global variables. I could not answer the question why the compiler was not saying anything to this construct. I have told them to put those options in the "DevCpp/Menu/tools/compiler options" settings.

[Narue]

>I could not answer the question why the compiler
>was not saying anything to this construct.
Compilers are only required to notify you about constraint violations. Further errors, and warnings in particular, are specific to the compiler and are there only because they make a compiler more user-friendly and thus, more marketable. That particular construct is not a constraint violation, so a diagnostic message isn't required.

[White-Gandalf]

OK, by pure curiosity: Do you know, where the optionality of delivering a defined return statement is defined in the cpp definition? (For example at http://www.open-std.org/jtc1/sc22/open/n2356/contents.html ?)

I can only find the very wishy-washy expressed note:

Flowing off the end of a
function is equivalent to a return with no value; this results in
undefined behavior in a value-returning function.

(What should "flowing of an end of a function" mean? What should be said about a function returning a pointer? Or is a "value" at this point meant as an alternative notation of "anything". Isn't such behavior - whether meant to be standard or not - a sign of unsuitability for serious matters? - I simply cannot imagine that this should have been element of the standard all over the years...)

----

Well, at http://pdhut.50megs.com/vczone/articles/diffc/diffc.htm I find for C++:

The C++ language requires that all possible control paths through a function return a value that is the same type as the return type specified by the function prototype. If this is not the case, a fatal error is generated by the compiler.

...and even for C(without ++):

In C, if a control path ends in a return statement that returns a value that is of a different type than that specified in the function prototype, a warning may be generated but compilation will continue.

...which is obviously to the contrary of the previous assumptions...

Other sites, too, look like being severe about that matter:
http://www.fredosaurus.com/notes-cpp/functions/return.html
or just
http://www.google.com/search?hl=en&q=return+statement+c%2B%2B+optional&btnG=Google+Search

What is - and just more mattering: what should be - the right thing?
It all strengthens my impression that this is a matter of a bug of the gnu compiler.

[Narue]

>I can only find the very wishy-washy expressed note
That's what I was looking for. I was having trouble navigating that craptastic interface.

>What should "flowing of an end of a function" mean?
When the function is executed, if you reach the end of the function without hitting a return statement, you've "flowed" off the end. For example:

void foo()
{
  cout<<"Test";
  cout<<"Test";
  // Flowing off the end here
}

>What should be said about a function returning a pointer?
Nothing special. The same rules apply.

>Or is a "value" at this point meant as an alternative notation of "anything".
"value" is meant as the operand to the return operator, the result of the return expression.

>Isn't such behavior - whether meant to be standard
>or not - a sign of unsuitability for serious matters?
Undefined behavior is lawyer speak for "seriously freakin' borked".

>I simply cannot imagine that this should have been
>element of the standard all over the years...
I'm not sure I understand the problem. It's clearly undefined and stated as such by the standard. If your compiler chooses not to warn about it, that's not the standard's problem.

>...which is obviously to the contrary of the previous assumptions...
How so? Neither of those quotes address the issue of failing to have any return statement at all. Falling off the end of a function does return a value of the correct type, but the value is indeterminate, which results in undefined behavior.

>what should be - the right thing?
The standard is the final word, period. There have been times where the standard managed to contradict itself in several places, but it was still the final word and we had to deal with the contradiction until it was corrected.

>It all strengthens my impression that this is a matter of a bug of the gnu compiler.
That's certainly possible. Or, because turning on your pedantic switches enables the warning, it's equally likely that it's a feature. Perhaps so that you can stub functions without being inundated with warnings during development.

[edit]Are you done editing your post now?[/edit]