Default return statements in C?

[techmologist]

I was recently writing a function to return the quotient of two Big Numbers, in which there were several if/else conditionals. Instead of having one return statement at the very end, I intended to have a separate return statement for each conditional block (this might be bad style, i don't know). Only I forgot to put a return statement in one of them. The weird thing is, the code still more or less worked--though not quite as expected--even when control flow entered that faulty block. Does the compiler somehow know to insert some default return value when it does not find a return statement where it is expected?

In this case, it returned the value of the same variable whose value I had returned in the previous block.

 

[Mark44]

If you have a function that is supposed to return a value, but you don't actually have a return statement (which seems to be the case for one block of your function), the function will return whatever happens to be in a particular register.

For example, if your function is supposed to return an int, but in one code path there is not return statement, the compiler does not automatically insert a default return value - the function returns whatever happens to be in the AX register.

I'm making certain assumptions here about the CPU architecture and so on, but I'm reasonably sure that this describes your situation as well.

The best practice is probably to have one return statement at the end of the code for your function. In each of your blocks in this function, rather than return some value, just set a result variable. Then when your function is about to be exited, return that result value. Your function should have one entry and one exit.

 

[techmologist]

Thank you, Mark44! That makes perfect sense, and your suggestion of one entry, one exit seems like good advice. I'm not an experienced programmer or computer user, and I mostly write C programs to help me do calculations. So this behavior was very puzzling to me. Thanks again

 

[D H]

If you have a function that is supposed to return a value, but you don't actually have a return statement (which seems to be the case for one block of your function), the function will return whatever happens to be in a particular register.

Maybe. Then again, maybe not. A function such as the one described in the OP will return something, but what that something is completely up to the whim of the compiler writers.

techmologist, what you have done with this function is to invoke "undefined behavior." That is something you never want to do.

Iif you had compiled with a bit stronger set of warning options the compiler would have told you something along the lines of "warning: control reaches end of non-void function." It is a good practice to use a stringent set of compiler options. The default options let too many real problems pass by unnoticed.

The best practice is probably to have one return statement at the end of the code for your function. In each of your blocks in this function, rather than return some value, just set a result variable. Then when your function is about to be exited, return that result value. Your function should have one entry and one exit.

<rant on>
I hate that particular programming standard. Loathe it, despise it, find it absolutely repulsive, ... This one point of entry / one point of return rule is a lazy solution for a real problem. It does not necessarily solve that problem, and it invites the use of goto. I have seen multiple waivers granted for the use of goto because of this stupid rule. The real problem is that functions that do things with resources must ensure those resources are treated safely, even in the face of erroneous conditions. No memory leaks, no locks inadvertently left locked, etc. The solution is to make a rule that addresses that narrow problem.
<rant off>

 

[techmologist]

Ahh, so there is some division on this idea of one-entry-one-exit? In that case, I'd like to hear a few more people chime in with their opinions. For simple programs like the ones I write, it seems like a good rule of thumb. I was mainly using multiple return statements to avoid deeply nested indention so that I wouldn't have to scroll to read a line of code (lazy). But for complex applications, it doesn't surprise me that such a general rule would find many exceptions.

You guessed right, D H. I was using default compiler options (again, lazy). Should probably know better. After finding the bug, I was surprised that it had both compiled and run without crashing.

 

[D H]

Yes, it is a good rule of thumb. If I had been involved in a code review of your code I probably would have asked why you wrote it that way. My problem is with people who want to make it a rule, period. There are just too many cases where an adroitly placed return (or even a whole bunch of returns) makes the code easier to understand, easier to maintain.

There are a lot of bad programming standards out there. This is one of them. Two more:

// Someone got burned 25 years ago by saying "if (ptr = NULL)"
// That this happened 25 years ago is irrelevant.
// That compilers complain about the above is irrelevant.
// That code reviews and testing should catch the above is irrelevant.
if (NULL == ptr)  ...

// Now "if (index <= 25)" looks inconsistent with the above.
if (25 >= index) ...// A history of the evolution of another rule.
// Here is how the code looked originally:
if (active) ...

// Some rule writer doesn't understand booleans. The above needs a rewrite.
if (active == true) ...

// Someone argued against the above rule: never compare a flag to true.
if (active != false) ...

// Someone else doesn't like negative conditions.
// Double negatives are OK, though.
// The final solution:
if (!active) ...

The single point of entry / single point of return is, in my mind, only marginally better than the above two atrocities (BTW, those are real standards at some installations).

Speaking of single point of entry: Is there any language other than Fortran that supports multiple points of entry in a procedure? That this rule is still called the "single point of entry / single point of return" is telling.

 

[Mark44]

Speaking of single point of entry: Is there any language other than Fortran that supports multiple points of entry in a procedure? That this rule is still called the "single point of entry / single point of return" is telling.

You're probably tacitly referring to high-level languages, but I think I remember seeing assembly code with different entry points for procs.