return statement at end of function

M

Marlene Stebbins

My program has code like this:

bigint bigSub(bigint minuend, bigint subtrahend)
{
bigint bigdiff;

bigInit(&bigdiff);

if(((cmp_ops(minuend.number, subtrahend.number))==1) &&
minuend.sign == POS && subtrahend.sign == POS)
{
bigdiff = abs_sub(minuend, subtrahend);
bigdiff.sign = POS;
bigdiff.size = strlen(bigdiff.number);
return bigdiff;
}
else if(((cmp_ops(minuend.number, subtrahend.number))==0) &&
minuend.sign == POS && subtrahend.sign == POS)
{
bigdiff = abs_sub(subtrahend, minuend);
bigdiff.sign = NEG;
bigdiff.size = strlen(bigdiff.number);
return bigdiff;
}
... /* several more if() blocks

/* no final return statement */
}

Some compilers don't complain at all; some issue warnings about missing
return values and some generate an error, interpreting the return value
as an int. What does the C standard say about this and what is standard
practice? I could use a goto, but...
 
K

Keith Thompson

Marlene Stebbins said:
My program has code like this:

bigint bigSub(bigint minuend, bigint subtrahend)
{
bigint bigdiff;

bigInit(&bigdiff);

if(((cmp_ops(minuend.number, subtrahend.number))==1) &&
minuend.sign == POS && subtrahend.sign == POS)
{
bigdiff = abs_sub(minuend, subtrahend);
bigdiff.sign = POS;
bigdiff.size = strlen(bigdiff.number);
return bigdiff;
}
else if(((cmp_ops(minuend.number, subtrahend.number))==0) &&
minuend.sign == POS && subtrahend.sign == POS)
{
bigdiff = abs_sub(subtrahend, minuend);
bigdiff.sign = NEG;
bigdiff.size = strlen(bigdiff.number);
return bigdiff;
}
... /* several more if() blocks

/* no final return statement */
}

Some compilers don't complain at all; some issue warnings about missing
return values and some generate an error, interpreting the return value
as an int. What does the C standard say about this and what is standard
practice? I could use a goto, but...

As long as there's no way to reach the final '}' without executing a
return, there's no real problem. If any of the if blocks are missing
a return statement, there is a problem. (I actually can't find the
passage in the standard that says what happens when a non-void
function terminates without executing a return statement.)

Some would argue that there should only be a single return statement
at the end of the function, but that's a matter of style.
 
S

S.Tobias

Keith Thompson said:
(I actually can't find the
passage in the standard that says what happens when a non-void
function terminates without executing a return statement.)

# 6.9.1 Function definitions
#
# 12 If the } that terminates a function is reached, and the value of
# the function call is used by the caller, the behavior is undefined.
 
C

Chris Torek

My program has code like this:

[much snippage, and some reformatting for vertical space]
bigint bigSub(bigint minuend, bigint subtrahend) { ...
if (...) { ...
return bigdiff;
} else if (...) { [etc]
return bigdiff;
}
/* no final return statement */
}

Some compilers don't complain at all; some issue warnings about missing
return values and some generate an error, interpreting the return value
as an int. What does the C standard say about this and what is standard
practice? I could use a goto, but...

The C standard has little to say about it -- the code is correct
as long as the "missing" (not really missing, just some compilers
think so) return statement is never reached.

In cases like this, I prefer to restructure the code, giving
something like either of these:

f_type f(args) {
...
if (...) {
...
return result;
}
if (...) {
...
return result;
}
/* at this point only one final case remains */
if (!final_case)
panic("f(): impossible situation");
...
return result;
}

or:

f_type f(args) {
...
if (...) {
...
} else if {
...
} else if {
...
} else {
panic("f(): impossible situation");
}
return result;
}

Obviously this second version can only be used if the "result"
variable (bigdiff in your original code) is always the expression
being "return"ed.

The middle version (my first version above) has the slight drawback
that the code is asymmetric -- the final case is not as indented
as the remaining ones.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top