value returned from a function

[noor.fatma]

Hi all,

if I declare a function as one returning int and do not return
anything from the function ,what will it return? for example.

the following function returns the value of sum correctly.

int sum1(int a,int b)
{

int sum;

sum=a+b;

//return sum;
}

Is there some rule defined?
Thanks,
Noor

 

[Richard Bos]

if I declare a function as one returning int and do not return
anything from the function ,what will it return? for example.

Anything random.

the following function returns the value of sum correctly.

No, it doesn't. It may seem, by accident, to do so on the implementation
you're using, but you're treading on a minefield.

int sum1(int a,int b)
{

int sum;

sum=a+b;

//return sum;
}

Is there some rule defined?

No. None whatsoever. It's not even guaranteed not to crash the computer.

Richard

 

[noor.fatma]

Hi Richard,

Thanks.

But I tried with three compilers ,VC,Turbo C and gcc. in all the three
cases I got the answer correct.

I found out by experiment that it returns the integer on which the
operation happens first.
for example.

int sum(int a,int b)
{

int sum,k;

k=a-5;

sum=a+b;

}

this returns the value of k correctly.

Thanks
Noor

 

[Ancient_Hacker]

I found out by experiment that it returns the integer on which the
operation happens first.

As others have stated, you can't depend on what gets returned. On some
systems, the return value comes back in a particular register, say ax.
Now jsut by chance, many compilers do arithmetic using the ax rgister
(on the x86, "ax" is the "main" arithmetic register, as the multiply
and divide operations cqan only be done on ax). So quite often you'll
find a arithmetic result in ax.

But not always-- a compiler is perfectly free to use a different
register, or trash ax after the arithmetic op, so you can't depend on
ax having any particular value. Just adding a statement, anywhere in
the function, can change ax. Or changing the optimization level, or
adding or subtracting a declaration can change it. So DONT DEPEND on
the function result getting set to anything reliable.


But other compilers return function results as the top item on the
stack, which if you don't set the return value, usually has something
unpredictable in it.

 

[Richard Heathfield]

(e-mail address removed) said:

Hi Richard,

Thanks.

But I tried with three compilers ,VC,Turbo C and gcc. in all the three
cases I got the answer correct.

No, you didn't. In all three cases you got the same result. That doesn't
mean you got the answer correct.

I found out by experiment that it returns the integer on which the
operation happens first.

A perfect example of the dangers of experimentation.

The experiment would have been useful if it had led you to ask: "I have a
function that is defined as returning an int value but which doesn't
actually do so. I observed identical behaviour on three different compilers
- in each case, it does <foo>. Is <foo> actually guaranteed by the
language, or is this just a coincidence?"

And, of course, the answer is that it is just a coincidence, and is
certainly not guaranteed by the language definition. It is unwise to rely
on this behaviour.

 

[Ben Pfaff]

(on the x86, "ax" is the "main" arithmetic register, as the multiply
and divide operations cqan only be done on ax)

The latter "fact" is not true. IMUL has forms with one, two, and
three operands. The two- and three-operand versions don't
necessarily involve AX. (MUL always involves the accumulator.)

This is why you shouldn't post off-topic stuff to comp.lang.c.

 

[John Bode]

Hi all,

if I declare a function as one returning int and do not return
anything from the function ,what will it return? for example.

the following function returns the value of sum correctly.

int sum1(int a,int b)
{

int sum;

sum=a+b;

//return sum;
}

Is there some rule defined?

Indeed, it invokes *undefined* behavior; it may appear to work
correctly, or it may return a garbage value, or it may do something
else entirely.

Add another statement after the addition (such as a printf() statement)
and see if you still get the result you expect.

 

[Keith Thompson]

Indeed, it invokes *undefined* behavior; it may appear to work
correctly, or it may return a garbage value, or it may do something
else entirely.

Add another statement after the addition (such as a printf() statement)
and see if you still get the result you expect.

If I recall correctly, falling off the end of the function doesn't
invoke undefined behavior, it merely returns an indeterminate result.
Attempting to *use* that result invokes UB.

 

[lawrence.jones]

if I declare a function as one returning int and do not return
anything from the function ,what will it return? for example. [...]
Is there some rule defined?

No. None whatsoever. It's not even guaranteed not to crash the computer.

In C99, it's a constraint violation and thus need not even compile.

-Larry Jones

These things just seem to happen. -- Calvin

 

[Keith Thompson]

if I declare a function as one returning int and do not return
anything from the function ,what will it return? for example. [...]
Is there some rule defined?

No. None whatsoever. It's not even guaranteed not to crash the computer.

In C99, it's a constraint violation and thus need not even compile.

Um, I don't think so.

N1124 6.8.6.4p1:

A return statement with an expression shall not appear in a
function whose return type is void. A return statement without an
expression shall only appear in a function whose return type is
void.

N1124 6.9.1p12:

If the } that terminates a function is reached, and the value of
the function call is used by the caller, the behavior is
undefined.

So this program neither violates a constraint nor invokes undefined
behavior (though it's horribly bad style):

int foo(void)
{
/* no return */
}

int main(void)
{
foo();
return 0;
}

Elsethread, I said that the value returned is indeterminate; I don't
think that's correct, though the effect is similar. If it were merely
indeterminate, then one might argue that, if foo() returned an
unsigned char, the caller could safely use the value, since unsigned
char has no trap representations. In fact, the behavior is undefined
becusae the standard says so.

From a programmer's point of view, all these details are, or should
be, irrelevant. Just Don't Do That.