Absent of return in old C++ codes

[Syncnister]

Hello everyone,

I have found some old c++ code with function defined as returning
boolean. The thing is that doesn't have any return statement at the
end. Looking at how the function is being used, suggesting that it is
expected to return true by default.

bool MyFunction()
{
if (sometest)
{
return false;
}

somecode;
somecode;

// missing return
}

My compiler is the latest GCC / G++ and the target system is HPUX. My
testing environment (where I found the problem) is Cygwin. I suspect
that in HPUX I'm getting return value true as default, but on cygwin
I'm getting false.

I am trying to explain why this happen (to my self) and to justify
adding return false before the function exit. Appreciate any thought.

[red floyd]

Syncnister wrote:

Hello everyone,

I have found some old c++ code with function defined as returning
boolean. The thing is that doesn't have any return statement at the
end. Looking at how the function is being used, suggesting that it is
expected to return true by default.

bool MyFunction()
{
if (sometest)
{
return false;
}

somecode;
somecode;

// missing return
}

My compiler is the latest GCC / G++ and the target system is HPUX. My
testing environment (where I found the problem) is Cygwin. I suspect
that in HPUX I'm getting return value true as default, but on cygwin
I'm getting false.

I am trying to explain why this happen (to my self) and to justify
adding return false before the function exit. Appreciate any thought.

Because the program is ill-formed. A good compiler should issue a
diagnostic.

[Paavo Helde]

Syncnister <ha*********@gmail.comwrote in news:b6e82241-d3e3-4764-8384-
5f**********@s13g2000prd.googlegroups.com:
[...]

bool MyFunction()
{
if (sometest)
{
return false;
}

somecode;
somecode;

// missing return
}

In the (paranoid?) fear of forcing any non-zero cost on the running code
the C and C++ languages allow to omit the return statement in code
branches which are never executed. The compilers thus only give warnings
for such code. If the branch is actually taken, you get undefined
behavior, i.e. anything can happen.

In this case, on Intel processors, what *probably* *might* happen is that
the register used for return value is not touched and after the function
return it contains some random value. The value is interpreted as a bool
by the calling function. The interpretation *probably* recognizes zero as
false and anything non-zero as true. Thus chances to get apparent
response 'true' *might be* greater, which might have misled the original
programmer to think that his code is correct.

The only way to fix the code is to add proper return statements (and
compile the code with all warnings enabled!). If the branch is never
executed, you don't lose anything; if the branch is executed you avoid
UB.

hth
Paavo

[Ron Natalie]

red floyd wrote:

Because the program is ill-formed. A good compiler should issue a
diagnostic.

It's not ill-formed. It's just undefined behavior.
The compiler is not required to figure out if the code
flows off the end at compile time.

[Dennis Handly]

Syncnister wrote:

I have found some old C++ code with function defined as returning
boolean. The thing is that doesn't have any return statement at the
end. Looking at how the function is being used, suggesting that it is
expected to return true by default.

No, it will return whatever is in the return register, R8 for IPF and
R28 for PA.

I suspect that in HP-UX I'm getting return value true as default

This is all random as mentioned. It depends on opt level, etc.