-1

I have some legacy C code that I compiled with gcc version 4.9.2 on Linux with return-type warning on [-Wreturn-type]. I have a function as below:

int somefn() {
   // .. do something ..
   // no explicit return statement
}

and the caller had the call as below:

if (somefn()){
   // handling of success
}
else {
  // handling of failure
}

When warnings were suppressed, compilation+linking went all ok, and at runtime, we may get surprises, What could go wrong?

Dr. Debasish Jana
  • 6,980
  • 4
  • 30
  • 69
  • What could go wrong...everything.... – Sourav Ghosh May 24 '17 at 11:16
  • 1
    Are you sure you make sense? First you say...`with return-type warning on [-Wreturn-type].` and then you say...`Since warnings were suppressed,`...what are you upto? – Sourav Ghosh May 24 '17 at 11:16
  • 2
    Just out of curiosity, why are you running gcc 2.95 in 2017? – unwind May 24 '17 at 11:17
  • 1
    @unwind if old code was written to gcc 2.95 conformance instead of ISO C conformance, then changing compilers could be a major undertaking. In those days the linux kernel, for example, could only be compiled with a specific version of specific compiler. If you want to recompile that kernel today then that's your only realistic option – M.M May 24 '17 at 11:18
  • 2
    Also , unclear why the question is tagged "gcc4.9" when it's about gcc 2.95 – M.M May 24 '17 at 11:19
  • I had some typos, for example gcc version and warning suppressed, corrected – Dr. Debasish Jana May 24 '17 at 13:03
  • I just shared by experience while going through a legacy code and my post analysis – Dr. Debasish Jana May 24 '17 at 18:34

2 Answers2

1

I compiled with gcc version 4.9.2 on Linux with return-type warning on [-Wreturn-type] The caller expected a true (in C, interpreted as non-zero) for success and 0 for failure. This is what was happening. Since a function that returns non-void, when called, space is created on the stack for the return value, then context is switched to the callee, and finally, when the control comes back to the caller, context is switched back popping all local variables from stack and keeping the return value there on stack to be popped by the caller after return from callee. Thus, having no explicit return statement caused some value to be returned. That is equivalent to having explicit return statement as ‘return 1;’ or 'return 0;' as appropriate. So, better (of course) would be to have explicit return statement e.g.

int somefn() {
   // .. do something ..
   if (..somecond..)
    return 0; // failure
   else
    return 1; // success
}

To avoid surprises, I would say, compilers should flag 'no return statement in function returning non-void' as error.

Dr. Debasish Jana
  • 6,980
  • 4
  • 30
  • 69
  • 1
    It's only an error if the caller uses the value; so the compiler should (in conforming mode) not flag the function. Actually it is impossible to always flag the function without false positives (halting problem). – M.M May 24 '17 at 11:16
  • @M.M yes true, I just shared my experience while trying to track a critical bug from a legacy code that missed explicit return statement, and after setting -Wreturn-type and going through trillions of warnings came out to this observation, you are 100% correct, so am I. – Dr. Debasish Jana May 24 '17 at 19:26
1

Quoting C11, chapter §6.9.1, Function Definitions, Semantics

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, the standard specifies the semantics of the function definition and it clearly states that (for a non-void function return type) a function which terminates without a return statement and the returned value is used in caller causes undefined behavior.

So, it accepts that syntactically writing a function as such will be possible, but attempt to make use of that will be UB. It does not state this as a constraint violation and I see no reason for a conforming compiler to produce an "error".

In case you want strict check (which is recommended, by the way), use -Werror option.

Sourav Ghosh
  • 133,132
  • 16
  • 183
  • 261