function works fine without return value in c++ [closed]

Question

I forgot to write return 'a'; in the show function and return 0; in main function but it works fine in Code::Blocks.

#include <iostream>

using namespace std;

char show()
{    
  cout<<"this is show function"<<endl;
}

int main()
{
  show();
}

I am using Code::Blocks 10.05 in Ubuntu 12.04. Why does this code work fine in Code::Blocks but not in Turbo C++?

Answer 1

If a function is declared to return a value, and fails to do so, the result is undefined behavior (in C++). One possible result is seeming to work, which is pretty much what you're seeing here.

As an aside, in C, you wouldn't actually have undefined behavior -- in C, you get undefined behavior only if you try to use the return value, and the function didn't specify a value to return.

Answer 2

The compiler should have issued at least a warning for not including a return statement in show(). I would expect the compiler to issue a message if the warning level of the compiler is increased. As other's have indicated, not returning a value is undefined behavior according to the standard.

This program will also not have a run time error, primarily because the results of show() are never used. If you used the results of show(), you will likely get some unexpected result, including what you expected.

Answer 3

UB as said before. Might work today, might not work tomorrow on a different processor/compiler.

For some fun forensics, here's a fun and mildly-related thing to try (orig in C, also "worked/bugged" in our C++ setup at the time), it was a fun bug for a bit:

• Define a function which returns a floating point in a c or cpp file, nothing complex, just float/double foo(){ whatever body; return someFloat;}.
• Use said function in a c file or cpp file (which will assume default-int), without including the header file. Note: depending on your compiler you might need to add a declaration of the wrong type (int foo();). Our compiler at the time just assumed the function was ok, didn't have the identifier issue without an included header.
• Call the second function (which uses the first) a few times throughout the code. Note that a value is added but never popped off the processor's floating point stack with each call to foo().
• Be amazed how NaN starts popping up in totally innocuous operations later on. Once that stack gets overflowed (the 9th call in our case), every FP operation becomes a NAN. So you get fun stuff like 10.0 + 1.0 => NaN.

The trick for us at the time was to find that offending function, since the NaN would occur much later, and not always in the same spot (enjoy the multithread on this one).

If you can reproduce this and have a debugger which lets you check out the processor's register state easily- this is a fun bug to play with. Ours at the time was a flavor of gcc 4.1 (or maybe 4.4, don't recall the exact year), with a 64-bit itanium processor.

(sorry to the mods for the extra stuff- not sure where that goes, but it is kinda related to the OP, if not feel free to copy this where it better belongs).