return statement at end of function

[Marlene Stebbins]

My program has code like this:

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

bigInit(&bigdif f);

if(((cmp_ops(mi nuend.number, subtrahend.numb er))==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(mi nuend.number, subtrahend.numb er))==0) &&
minuend.sign == POS && subtrahend.sign == POS)
{
bigdiff = abs_sub(subtrah end, 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...

[Keith Thompson]

Re: return statement at end of function

Marlene Stebbins <marlene@mail.c om> writes:[color=blue]
> My program has code like this:
>
> bigint bigSub(bigint minuend, bigint subtrahend)
> {
> bigint bigdiff;
>
> bigInit(&bigdif f);
>
> if(((cmp_ops(mi nuend.number, subtrahend.numb er))==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(mi nuend.number, subtrahend.numb er))==0) &&
> minuend.sign == POS && subtrahend.sign == POS)
> {
> bigdiff = abs_sub(subtrah end, 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...[/color]

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.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[S.Tobias]

Re: return statement at end of function

Keith Thompson <kst-u@mib.org> wrote:
[color=blue]
> (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.)[/color]

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

--
Stan Tobias
mailx `echo siXtY@FamOuS.Be dBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Chris Torek]

Re: return statement at end of function

In article <pmyKd.196917$X k.60264@pd7tw3n o>
Marlene Stebbins <marlene@mail.c om> wrote:[color=blue]
>My program has code like this:[/color]

[much snippage, and some reformatting for vertical space]
[color=blue]
>bigint bigSub(bigint minuend, bigint subtrahend) {[/color]
...[color=blue]
> if (...) {[/color]
...[color=blue]
> return bigdiff;
> } else if (...) {[/color]
[etc][color=blue]
> 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...[/color]

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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.