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()

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++?

  • What is the error, and why are you trying to use Turbo C++?
    – user16764
    Jun 19, 2012 at 4:08
  • Why can't you just return a value from each of your functions?
    – grc
    Jun 19, 2012 at 4:37
  • @user16764 . I don't Remember the error but in code block runs fine. I want 2 know what is happening inside . i just check same thing in turbo c++ Jun 19, 2012 at 16:30
  • How is this question now on-topic? The two new edits are the same with other words and formatting... Dec 11, 2019 at 0:25

3 Answers 3


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.


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.


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).

  • Interestingly, this won't work in MSVC without a surprising amount of effort. Visual C++ emits an error when assuming default-int, and includes functions' return types in their mangled names (allowed but not required, IIRC), providing a surprising level of protection against Machiavelli like this. Aug 18, 2019 at 20:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.