Redundant return

[quarkLore]

I have seen redundant return statements at the end of function. e.g.
void init_function(void)
{
a_init();
b_init();
c_init();
return;
}
I checked the generated code in GCC Compiler 3.2.2 on Red Hat Linux it
is ignored so it not harmful to use this.

Has anybody got any problem/issues with this on any compiler/platform?

 

[robertwessel2]

I have seen redundant return statements at the end of function. e.g.
void init_function(void)
{
a_init();
b_init();
c_init();
return;
}
I checked the generated code in GCC Compiler 3.2.2 on Red Hat Linux it
is ignored so it not harmful to use this.

Has anybody got any problem/issues with this on any compiler/platform?

That's perfectly valid, if pointless. Any compiler that does not
handle it is broken.

 

[William Hughes]

That's perfectly valid, if pointless.

Pointless? Maybe, maybe not. Certainly in this case no code is
produced.
On the other hand, a coding style in which you require an explicit
return
for all functions has advantages, especially if you use more than
one exit point.
- William Hughes


Any compiler that does not

 

[Richard Heathfield]

quarkLore said:

I have seen redundant return statements at the end of function. e.g.
void init_function(void)
{
a_init();
b_init();
c_init();
return;
}
I checked the generated code in GCC Compiler 3.2.2 on Red Hat Linux it
is ignored so it not harmful to use this.

Right, and some people value its documentary effect. It reminds the
reader that this is a void function, stopping him from pointlessly
thinking "so where's the return value then?", and some people use it to
mean "DONE! Phew!"

Has anybody got any problem/issues with this on any compiler/platform?

No, it's perfectly legal C and it does no harm whatsoever.

 

[bytebro]

I have seen redundant return statements at the end of function. e.g.
void init_function(void)
{
a_init();
b_init();
c_init();
return;
}

To add to the comments already made, I would say that declaring a
function of type 'void' does not mean that it doesn't return, it means
that it doesn't return a value.

IMHO, 'Dropping off the end' of a function is just laziness, and from
a purely style point of view, I would always put an explicit return.

 

[Chris Dollin]

To add to the comments already made, I would say that declaring a
function of type 'void' does not mean that it doesn't return, it means
that it doesn't return a value.

IMHO, 'Dropping off the end' of a function is just laziness, and from
a purely style point of view, I would always put an explicit return.

IMAO, putting an unnecessary return at the end of a function is just
waffling, and from a purely style point of view, I would always eliminate
such a return. It's just noise.

--
Jena user conference, September 2007: http://hpl.hp.com/conferences/juc2007/
"He's dead, Jim, but not as we know it." Unsaid /Trek/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

 

[William Hughes]

IMAO, putting an unnecessary return at the end of a function is just
waffling, and from a purely style point of view, I would always eliminate
such a return. It's just noise.

O boy a style war!

It's not just noise. Consider what happens if the function
undergoes multiple changes. The first change comes in response to
a bug where the program mysteriously crashes. Turns our that b_init()
will
crash if a_init fails. So the first change is

void init_function(void)
{
if(!a_init())
return;
b_init();
c_init();
}

things are OK for a while (no bugs have to be fixed), but a change in
OS means
that it is no longer easy to tell if a_init() failed or not. So a
change is
made so init_function returns SUCCESS or FAILURE

int init_function(void)
{
if(!a_init())
return FAILURE;
b_init();
c_init();
}

(Whoops, didn't catch the implicit return, the change should not
have been done by someone who assumed all returns were explicit.
Don't use that
contractor again.). Falling off now causes undefined
behaviour, which in this case is to return the value of a register,
which
happens to be non-zero, and tests false when compared to failure.
Things look fine. Until the next release of the compiler, when the
register now contains 0.


The fact that four programmers are involved does not help.


- William Hughes

 

[Richard Heathfield]

Chris Dollin said:

bytebro wrote:


IMAO, putting an unnecessary return at the end of a function is just
waffling, and from a purely style point of view, I would always
eliminate such a return. It's just noise.

IMDO, can I just say that, whilst I disagree with Chris, it is clear
that the rules of C allow either approach, that neither approach is
dangerously flawed, and that we need not fall out over such minor
issues of style?

 

[Chris Dollin]

Chris Dollin said:


IMDO, can I just say that, whilst I disagree with Chris, it is clear
that the rules of C allow either approach, that neither approach is
dangerously flawed, and that we need not fall out over such minor
issues of style?

Surely.

I was provoked by bytebro's accusations of "laziness"; it's not lazy
to avoid needless work.

--
JUC 2007, submit: http://hpl.hp.com/conferences/juc2007/submission.html
"Go not to the Elves for counsel, for they will answer both no and yes."/tLotR/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

 

[Chris Dollin]

O boy a style war!

S'not a style war: it's an attitude war.

It's not just noise.

It's just noise /in that function/.

Consider what happens if the function undergoes multiple changes.

(fx:snip)

Sometimes bad things happen, especially without unit tests and
compilers that give helpful diagnostics. I'd hesitate to ascribe
the unwritten return as the dominant cause of the problem you
describe.

--
Jena user conference, September 2007: http://hpl.hp.com/conferences/juc2007/
"It is seldom good news." ~Crystal Ball~, /The Tough Guide to Fantasyland/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

 

[Tak-Shing Chan]

Surely.

I was provoked by bytebro's accusations of "laziness"; it's not lazy
to avoid needless work.

Calm down; a good programmer is a lazy programmer.

Tak-Shing

 

[William Hughes]

S'not a style war: it's an attitude war.

Is too.

It's just noise /in that function/.

No more than the white space is "just noise /in that function/".
Neither is needed by the compiler.

(fx:snip)

Sometimes bad things happen, especially without unit tests and
compilers that give helpful diagnostics. I'd hesitate to ascribe
the unwritten return as the dominant cause of the problem you
describe.

Not claimed. Only that a style rule "always use explicit returns"
might be of practical use and thus an example cannot be
dismissed as "just noise".

-William Hughes