return statement at end of function

Discussion in 'C Programming' started by Marlene Stebbins, Jan 28, 2005.

  1. 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...
     
    Marlene Stebbins, Jan 28, 2005
    #1
    1. Advertising

  2. Marlene Stebbins <> writes:
    > 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.

    --
    Keith Thompson (The_Other_Keith) <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.
     
    Keith Thompson, Jan 28, 2005
    #2
    1. Advertising

  3. Marlene Stebbins

    S.Tobias Guest

    Keith Thompson <> wrote:

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

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
     
    S.Tobias, Jan 28, 2005
    #3
  4. Marlene Stebbins

    Chris Torek Guest

    In article <pmyKd.196917$Xk.60264@pd7tw3no>
    Marlene Stebbins <> wrote:
    >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.
    --
    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.
     
    Chris Torek, Jan 29, 2005
    #4
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Klatt
    Replies:
    2
    Views:
    396
    Michael Klatt
    Sep 19, 2004
  2. Seong-Kook Shin
    Replies:
    1
    Views:
    520
    Richard Bos
    Jun 18, 2004
  3. Greenhorn
    Replies:
    15
    Views:
    880
    Keith Thompson
    Mar 6, 2005
  4. Replies:
    3
    Views:
    344
    Clark S. Cox III
    Sep 11, 2006
  5. alex
    Replies:
    3
    Views:
    555
    Richard Cornford
    Dec 28, 2006
Loading...

Share This Page