Related to basic c programming about function return type.

[Raj12]

Why the sum function returns proper value even after remove/comment the return statement in sum function definition.?

why it is not throwing any errors>>>???

#include<stdio.h>
int sum(int, int);

int main()
{
	int n1=2, n2=22;
	printf("sum = %d", sum(n1, n2));
}
 int sum(int a, int b)
{
	int c;
	c = a+b;
	//return c;
	
}

[Grime]

You are allowed to define functions with types and without variable names, that only tells the compiler what types it must expect to see in the function arguments (don't ever do this, other than when you're writing prototypes). But functions are not supposed to be used this way (maybe they made it legal specifically for function prototypes, I wouldn't know).

So that's why the prototype doesn't give an error.

Also it doesn't really matter what variable names the prototype gives its parameters because they will be overridden by the function redefinition (the one below main in your program).

It's only important that
(1) The function prototype doesn't have a body.
(2) Function identifier of the function prototype is the same as the redefined function.
(3) Return type of the function prototype is the same as the redefined function.
(4) Parameter types of the function prototype are the same as the parameter types of the redefined function.

(1) -> shouldn't be redefining the function body (hence can't).
(2) -> needed to identify function
(3,4) -> distinguish the prototype from other overloads of functions with the same identifier.

[booradley60]

@Grime, I think you missed what OP was asking.

@Raj12. It returned the proper value because your particular compiler happened to make it so in this situation. The behavior is undefined. Don't do it. You have no guarantees on how your compiler might treat it 20 minutes from now.

[Grime]

Oh my god, I could have sworn the question was asking about why the prototype wasn't throwing an error. I can't tell you how freaked out I am because I even remember a comment near the prototype declaration. This is creepy. Oh woww I could have sworn but the thread doesn't even say "edited".

And no the program should not work without the return statement. I don't think there's a compiler that is intelligent enough to guess what must be returned. So we're missing some details.

[Peter87]

Your compiler should be able to warn you about these sort of things. If you are using GCC or Clang you should at least use the -Wall compiler flag.

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

int sum(int a, int b)
{
	int c;
	c = a+b;
	//return c;
	
} // warning: no return statement in function returning non-void 

[JLBorges]

> why it is not throwing any errors>>>???

The standard does not demand that undefined behaviour must be diagnosed as an error.

Every compiler will at least generate a warning (unless warnings are not enabled).
http://coliru.stacked-crooked.com/a/cfa2c9f011471f8d

Some compilers will actually generate an error (this is good).
https://rextester.com/ULKKV42021

[Peter87]

Some compilers will actually generate an error (this is good).

It's probably good, but I don't believe it is correct, strictly speaking, because you only get undefined behaviour if you actually reach the end of the function.

[JLBorges]

The Microsoft compiler is quite good in that respect; it generates an error only if no control path returns a value.

For instance, this is just a warning:

int sum(int a, int b)
{
	int c;
	c = a+b;
	
    if( a == 999 ) return c;
	
}

https://rextester.com/CUYCM29783

Of course, one could argue that (the earlier version of) the function may never be actually called at run-time.

Note: I'm not sure whether the standard clearly states that UB is a pure run-time phenomenon.
What does "uses" in

when a program uses an erroneous construct

mean?

[Peter87]

I'm not sure but it seems reasonable that it is allowed to give an error if it can prove that undefined behaviour will always happen, but that isn't what it's doing. Removing the call to the function so that it never gets called still generates an error.

[Raj12]

Thanks all for your replies,
Actually I guess that it is undefined behavior. But not compromising with my guess. Even i thought it depends on compiler or error/warning settings of these respective editors.

I tried this in both codeblocks & devc++ editors. In both editors 'sum' function is returning right correct 'c' value.

didn't tried in turboC editor or in gcc..

[Grime]

Wait.. did it actually compile and return a proper value or it didn't compile and you ran the previous version thinking it compiled?

Because there ain't no way a compiler should be able to guess the value to return from a function when a return statement is not specified at all.

edit: you must have meant that the function returned 0 and sum was 0. I misunderstood.

But wait you said "returning right correct 'c' value".. In that case I think it didn't compile and you mistook it to have compiled, if it did indeed return a proper value for 'c'.

[Raj12]

Hi Just now I tested this by modifying the compiler settings/options in devC++ editor. Now it is showing that as warning.

Still I didn't understand why such important standard/rule is showing as warning(after modifying the options) not as an error.

[Ganado]

To my knowledge, it's mostly because C++ still has a lot of old behavior due to how things worked in C. For example, in C, the return value of a function was implied to be int if none was given. It was still considered valid code when a function that returned int didn't actually return int, as long as the programmer didn't try to use the return value. Yeah it's gross stuff.

More-modern languages like C# will issue compiler errors if it can be determined at compile-time that a non-void function can end without returning a value.

If you build with -Wall, you will catch most of the 'gotcha' errors of C++.
If you give -Werror, all warnings will be treated as errors. This can later be fine-tuned if you discover a warning that you know you want to ignore (but I do not suggest it).

[Peter87]

Raj12 wrote:

I tried this in both codeblocks & devc++ editors.
...
didn't tried in turboC editor or in gcc..

Code::Blocks and Dev-C++ are IDEs that often use the GCC compiler, just saying.

Grime wrote:

Because there ain't no way a compiler should be able to guess the value to return from a function when a return statement is not specified at all.

I have seen it happen quite a few times with code posted here. It appears that the value of the last expression often ends up being stored where the return value is expected when optimizations are turned off.

Ganado wrote:

More-modern languages like C# will issue compiler errors if it can be determined at compile-time that a non-void function can end without returning a value.

People that want to squeeze maximum performance out of C++ might not like this. They might want to leave out the return statement from the end of a function if they know that it should never be reached. Of course it would be better if the default was safe and people had to opt-in if they wanted the unsafe, but that would probably break too much existing code. It's not really a problem if we just make sure to enable warnings.


Raj12, If you want to check for undefined behaviour at runtime you can also use -fsanitize=undefined.

ubsan wrote:

test.cpp:9:6: runtime error: execution reached the end of a value-returning function without returning a value

[Ganado]

It's not really a problem if we just make sure to enable warnings.

Completely agree, my point was just that other languages offer more protections by default, if that is desired. C++ compiler defaults definitely are more on the side of the "you're on your own" mentality, unless told otherwise. I'm not declaring that it's right or wrong, just saying how it is.