A nice article and clearly a bug bear issue in software which exhibits these traits. Thanks. If the programmer did not see fit to define a sound interface with their program through attention to detail over return values, I would assume quality issues abound with the rest of the software, and would not hesitate to assume compiling it could result in a program which deletes all my data. [Through programmer incompetence or compiler-writer foolhardiness. They are invoking undefined behaviour, after all. :-)]

Some questions / remarks:

Common case behaviour

In reality, despite the standards, how do compilers behave in the common case? If I wanted to see the effects of this for myself, in code I compile, how would I do so?

I suspect the common case is that a (sane) compiler assumes what the programmer intended and synthesises a return of 0? This is certainly the behaviour I experience with gcc on a generic GNU/Linux x86 box. For example, the below:

#include <iostream>

using namespace std;

int main(void)
{
        int x = 3+4 * 5;
        cout << x << endl;
}

Select all Open in new window

compiles down to:

000000000040082d <main>:
  40082d:       55                      push   %rbp
  40082e:       48 89 e5                mov    %rsp,%rbp
  400831:       48 83 ec 10             sub    $0x10,%rsp
  400835:       c7 45 fc 17 00 00 00    movl   $0x17,-0x4(%rbp)
  40083c:       8b 45 fc                mov    -0x4(%rbp),%eax
  40083f:       89 c6                   mov    %eax,%esi
  400841:       bf 80 10 60 00          mov    $0x601080,%edi
  400846:       e8 75 fe ff ff          callq  4006c0 <_ZNSolsEi@plt>
  40084b:       be 30 07 40 00          mov    $0x400730,%esi
  400850:       48 89 c7                mov    %rax,%rdi
  400853:       e8 c8 fe ff ff          callq  400720 <_ZNSolsEPFRSoS_E@plt>
  400858:       b8 00 00 00 00          mov    $0x0,%eax
  40085d:       c9                      leaveq 
  40085e:       c3                      retq   

Select all Open in new window

In particular, the compiler in this case seems to have synthesised an explicit mov of constant value zero to EAX before the return, presumably by assumption that this is what I intended when flowing off the end without an explicit return statement.

I appreciate the GNU Compiler Collection is a behemoth, so what do I need to do to actually observe random values returned from the accumulator register? Use some other simplistic / esoteric compiler, perhaps a very simple one which receives little attention and generates code for some relatively obscure architecture? Something else?

To be clear, I am not advocating a wilful disregard for the standard; quite the contrary. However, I often find constructive examples can be useful in motivating a change in programmer behaviour, rather than arguments from standards (which often seem to fall on deaf ears or false arguments of "it doesn't affect me" or "my compiler is better than that").

Compiler warnings

Should the compiler warn me if there exists a path in the flow graph of a function returning a non-void type which fails to explicitly call return before the end of the function? Should it do this for the main method? Details of specific compilers are well outside the scope of the article, but I note in gcc's man page, the return-type warning explicitly excludes warning about the main method. Why should this be the case?

For C++, a function without return type always produces a diagnostic message, even when -Wno-return-type is specified.  The only exceptions are main and functions defined in system headers.

Infinite loops

What are the correct semantics here? Do I need to / should I be forced to include a return value? What about if I do this outside main(), where switching on return-type warnings throws an error about a missing return statement which would otherwise never be reached? (Assuming C++)

int main(void)
{
        while (true)
        {
                // do something
        }
}

Select all Open in new window

Other functions

The following compiles but I presume it would be unwise to assume that anything will be well-defined after the call to foo() in main() which excludes a return statement?

int foo(int x, int y)
{
        /* something happens here */
}

int main(void)
{
        int bar = foo(3, 4);
}

Select all Open in new window

These questions / remarks are not intended as a criticism of the article, so please don't misconstrue them as such! There are a fair few nuances in such a seemingly simple topic which are worth further exploration.

So, thoughts?

>> In reality, despite the standards, how do compilers behave in the common case

It's really hard to say because it depends on both the compiler and the optimization level to which the code has been compiled. Generally, compilers use the accumulator to return values so whatever was last placed in that register is what will be used. There are no guarantees to this; however, and the only sane (and correct) answer I can give you is that the behaviour is undefined.

>> compiles down to:
Remember, it depends what optimization level you built with. The outcome in terms of assembly code can be very different depending on whether you built optimised for speed or performance and to what level you optimise to.

>> seems to have synthesised an explicit mov of constant value zero to EAX before the return
If this is C++ then, yes, it will.

"Interestingly, whilst the main function MUST be defined to return an int, in C++ you don't have to actually return anything from main. The main function is treated as a special case; whereas, if you omit a return value the C++ runtime will automatically return zero for you."

I can't say for sure, but I have a feeling the C++ standards council made this change to account for the fact people were declaring main to return void. If you were to do the same here you would probably still see zero returned due to the fact the accumulator is being zero'd out; howver, in truth the behaviour is undefined - always was and alway will be (at least until the standards council say otherwise).

>> so what do I need to do to actually observe random values returned from the accumulator register?
Change there return type to void and compile as C not C++ code.

Or, you could try this...

#include <ctime>
#include <cstdlib>

int foo()
{
   return rand();
}

int bar()
{
   // look ma' no return value!
}

int main()
{
   srand((unsigned)time(0));
   
   foo();
   
   return bar(); // should return the return value of foo() (random)
}

Select all Open in new window

>> Should the compiler warn me if there exists a path in the flow graph of a function returning a non-void type which fails to explicitly call return before the end of the function?
Interestingly enough this is not considered an error to not return a value from a function, it is considered to be undefined behaviour. This means the compiler does not have to generate an error but it will probably generate a warning (as long as warning levels are high enough). I suspect the reason is because it is possible to embed assembly into C/C++ code and so the function stack may be modified by the programmer outside the semantics of the C/C++ compiler's remit.

>> I note in gcc's man page, the return-type warning explicitly excludes warning about the main method. Why should this be the case?
Almost certainly because you can embed assembly into manipulate the function's stack-frame, which might be used to generate perfectly valid code but which the C/C++ compiler cannot validate and so will generate a warning.

>> Infinite loops - What are the correct semantics here? Do I need to / should I be forced to include a return value?
The compiler doesn't care - for the sake of sane program exit, maybe :)

>> where switching on return-type warnings throws an error about a missing return statement which would otherwise never be reached?
Well, that's a completely different problem - one of inaccessable control paths. Again, the standard does not mandate any warning be given for this and so that is compiler specific.

Other functions - The following compiles but I presume it would be unwise to assume that anything will be well-defined after the call to foo() in main() which excludes a return statement?
It's probably more correct to say the result is platform specific rather than undefined because it's really down to how the compiler works and it may be that this is actually intended (see my previous observation about embeding assembly). This code is not erroneous, it's just going to behave in a way that is arbitrary unless the programmer really knows what's going on at the assembly level and is controling it in some way.

>> These questions / remarks are not intended as a criticism of the article, so please don't misconstrue them as such!
All interesting points that makes me feel a separate article might be worth writing to cover in more detail the nuances of why there are somethings that would seem completely erroneous that the compiler will let you do and why somethings are undefined and some are unspecified (and what the difference is).

Matt, I hope my comments, above, help.

Awesome! Thank you ;-)

What a good, clear to the point, concise and clear short description about the difference of C and C++, and its scope of applications ........ thanks for this!  I strongly agree based in my short experience in embedded systems and mains stream programming.

Nice article, but I do have so reservations about placement new in general.

Firstly, you could probably achieve the same (or quite similar) performance gains by allocating objects rather than pointers to objects in the vector.

My main concern with placement new is that its semantics are very different from normal operator new and a lot of caveats need to be considered. For example, if the constructor of the object being supplanted throws the memory it is being supplanted into will leak because, unlike normal construction semantics, there is nothing to release that memory. This may or may not lead to a problem depending upon how your memory pool is managed.

My point is that placement new requires some very special care when being used and shaving a few microseconds for heap allocations when a different design might achieve the same result is probably not a good enough reason for making use of this feature of C++.

Just my 2 pence worth.

Great article for beginners... received my "yes" vote above.

I wholeheartedly agree, thank you very much!
Voted yes above, also.

Thanks torimar for your comment. Glad you found it a pleasure to read.

Awarded Editors' Choice

mbizup
EE Page Editor

Good article!  Got my YES vote!

Thank you Dan.

It is not a good idea to write code like

std::cout<<std::endl<<std::endl<<"text"

Select all Open in new window

And it's not good to use std::endl instead of '\n' just to use some different thing.
The '\n' and std::endl differs so that std::endl not only prints '\n' char, it flushs a stream buffer else.
If you aware that program can suddenly crash, you should write std::endl to ensure that buffer will be flushed, and text will be written to stdout just after writing statement (you write "text\n"). But if you just srart to write a text, why do you flush a buffer? Not just flush it, you flush it twice!.

If you want to separate leading '\n' from string, you can just write

std::cout<<"\n\n" "text"

Select all Open in new window

I think it's more readable, and it won't do useless work.

2x2makes11,

Whilst your point is valid it's not really the point of the article and is, thus, really unimportant in the context of what this article is actually discussing.

Good article!  You explained it very well.  I look forward to additions to this series.