opinion on return;

0 views
Skip to first unread message

Tom Leylan

unread,
May 8, 1992, 6:07:19 PM5/8/92
to
Just wondering... not that I'll change my habits but:

What do people think about the explicit use of a return statement in a
function that returns void ?

void test()
{
/* some code */
return;
}

I've heard some people argue that the absence of the return statement is
clearer in that if they don't see one it implies no return value. I seem
to always argue in favor of explicitly stating one's intentions and there
is a slight added benefit of making you think (for a moment) about the
return value.

I don't need long explanations just a "l never do", "I always do" sort of
answer.

thanks, tom

Preston F. Crow

unread,
May 8, 1992, 9:01:45 PM5/8/92
to

>Just wondering... not that I'll change my habits but:

>What do people think about the explicit use of a return statement in a
>function that returns void ?

>void test()
>{
> /* some code */
> return;
>}

I'm used to using "return(VALUE);" in non-void functions, so I would
(and once tried) "return();" for a void function. I am still disapointed
that I can't do that. As to your question, I can't see that it makes
any difference unless you put some comment after the return explaining
something about why your done with the function. Consequently, I
would fall into the "I never do" category.

--PC
--
(9966269*48+1) | (2^9966269)-1
Over 3 million digits factored on a 386-20!
"Performance through programming"

Jos Horsmeier

unread,
May 9, 1992, 5:57:14 AM5/9/92
to
In article <1992May8.2...@pegasus.com> tle...@pegasus.com (Tom Leylan) writes:
|Just wondering... not that I'll change my habits but:

|What do people think about the explicit use of a return statement in a
|function that returns void ?

|void test()
|{
| /* some code */
| return;
|}

[ ... ]

|I don't need long explanations just a "l never do", "I always do" sort of
|answer.

I'm in the 'I never do that' club. What else is the void function supposed
to do when it reaches the last right curly brace? Fall through into the
next function in my file or something ;-)

Jos aka j...@and.nl

Steve Clamage

unread,
May 9, 1992, 11:55:36 AM5/9/92
to
j...@and.nl (Jos Horsmeier) writes:

>In article <1992May8.2...@pegasus.com> tle...@pegasus.com (Tom Leylan) writes:

>|What do people think about the explicit use of a return statement in a
>|function that returns void ?

>What else is the void function supposed

>to do when it reaches the last right curly brace? Fall through into the
>next function in my file or something ;-)

I once worked on a limited-edition computer with its own progamming language
which did just that! There were no begin-end delimiters for functions.
The keyword "function" introduced the start of a function. If you
forgot the "return" at the end, code would fall through into the beginning
of the next function in memory, if there was one, or to the next word of
memory in any case. This produced bizarre program behavior which was hard
to find. The machine didn't use a stack, and return addresses were kept
in a reserved register, so the code could run for quite a while before
going bonkers somewhere far removed from the missing "return".

For administrative reasons it was not possible to change the language
to fix this problem, even though everyone realized it was a design error.
--

Steve Clamage, TauMetric Corp, st...@taumet.com
Vice Chair, ANSI C++ Committee, X3J16

John Gordon

unread,
May 9, 1992, 1:26:04 PM5/9/92
to
cr...@coos.dartmouth.edu (Preston F. Crow) writes:

>I'm used to using "return(VALUE);" in non-void functions, so I would
>(and once tried) "return();" for a void function. I am still disapointed
>that I can't do that. As to your question, I can't see that it makes

However, just plain "return;" will work for a void function.

---
John Gordon
gor...@osiris.cso.uiuc.edu Be a *quality* slaveowner. Buy American!

Stan Brown

unread,
May 9, 1992, 4:33:46 PM5/9/92
to
In article <1992May9.0...@dartvax.dartmouth.edu> cr...@coos.dartmouth.edu (Preston F. Crow) writes:
>I'm used to using "return(VALUE);" in non-void functions, so I would
>(and once tried) "return();" for a void function. I am still disapointed
>that I can't do that.

Actually, the analogy works quite wekk if you omit the redundant
parentheses. You can then write
return VALUE;
for a value-returning function and
return;
for a void function.

return is a statement, not a function like exit( ). return takes an
expression, and it never needs parentheses at the outer level.

Reference, ANSI sec 3.6.6 and 3.6.6.4; ISO sec (I believe) 6.6.6 and
6.6.6.4.
--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA br...@ncoast.org

Phil Howard

unread,
May 9, 1992, 4:39:24 PM5/9/92
to
st...@taumet.com (Steve Clamage) writes:

>For administrative reasons it was not possible to change the language
>to fix this problem, even though everyone realized it was a design error.

Makes one feel contempt for the people that sit around all day writing up
all those nasty "adiminstrative reasons".


>Steve Clamage, TauMetric Corp, st...@taumet.com
>Vice Chair, ANSI C++ Committee, X3J16

Of course we would not have such problems with a standardized language.
--
/***********************************************************************\
| Phil Howard --- KA9WGN --- p...@netcom.com | "The problem with |
| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/

Lars Peter Fischer

unread,
May 9, 1992, 8:50:14 PM5/9/92
to
>>>>> "Tom" == Tom Leylan (tle...@pegasus.com)

Tom> void test()
Tom> {
Tom> /* some code */
Tom> return;
Tom> }

Why waste lines stating the obvoius? Should we add a few "x = x;"
lines, too? More lines means more code to read, noting else.

/Lars
--
Lars Fischer, fis...@iesd.auc.dk | It takes an uncommon mind to think of
CS Dept., Aalborg Univ., DENMARK. | these things. -- Calvin

Tom Leylan

unread,
May 10, 1992, 7:59:23 AM5/10/92
to
In article <26...@dozo.and.nl> j...@and.nl (Jos Horsmeier) writes:
>
>I'm in the 'I never do that' club. What else is the void function supposed
>to do when it reaches the last right curly brace? Fall through into the
>next function in my file or something ;-)

Jos,

I've gotten a few email responses and you're in the majority but (in my
view "thankfully") I'm not alone in "always doing it".

It isn't supposed to control anything of course but to assist a programmer
not entirely unlike commenting code. Clearly I can read the code and often
don't require the comment but that doesn't make a case for leaving out
comments.

In any case, I realize that I'm "anal retentive" about my programming
habits but it works for me and I always teach people to dot the i's and
cross the t's knowing that they will form their own opinions as they
get more used to the language.

Thanks.

tom

D'Arcy J.M. Cain

unread,
May 10, 1992, 9:45:27 AM5/10/92
to
tle...@pegasus.com (Tom Leylan) writes:
>What do people think about the explicit use of a return statement in a
>function that returns void ?

I almost never do. One exception is:

void foo(int x) /* I'll create a function here one day */
{
return;
}

Sort of draws my attention to incomplete code.

--
D'Arcy J.M. Cain (darcy@druid) |
D'Arcy Cain Consulting | There's no government
Toronto, Ontario, Canada | like no government!
+1 416 424 2871 DoD#0082 |

Joe Wright

unread,
May 10, 1992, 2:36:45 PM5/10/92
to
tle...@pegasus.com (Tom Leylan) writes:
: Just wondering... not that I'll change my habits but:

:
: What do people think about the explicit use of a return statement in a
: function that returns void ?
:
: void test()
: {
: /* some code */
: return;
: }

The use of 'return' in this sense is probably harmless, but useless.
All functions return to the caller. The 'return' statement is used
to return a value or to quit executing before the end of a function,
for example:

void test() {
/* some code */

if (cond)
return;
/* more code */
}

--
Joe Wright al...@wyvern.twuug.com

John J. Rushford

unread,
May 10, 1992, 6:59:40 PM5/10/92
to
In article <1992May10....@druid.uucp> da...@druid.uucp (D'Arcy J.M. Cain) writes:
>tle...@pegasus.com (Tom Leylan) writes:
>>What do people think about the explicit use of a return statement in a
>>function that returns void ?
>

Its a waste of code. If you use lint you'll see that it doesn't complain
when a void function does not return anything.

John
rushpc!j...@csn.org

Kaleb Keithley

unread,
May 11, 1992, 11:58:09 AM5/11/92
to
>In tle...@pegasus.com (Tom Leylan) writes:
>Just wondering... not that I'll change my habits but:

>What do people think about the explicit use of a return statement in a
>function that returns void ?

>void test()
>{
> /* some code */
> return;
>}
>

Okay, I'll throw my $0.02 worth in.

If you're getting paid by the lines of code, add the return, but it's both
superfluous and redundant :-), and maybe it shows you don't really under-
stand the language.

Someone else submitted an example:

{
...
if (some_state)
return;
...
}

And they rationalized the use of the "return" by saying "...it terminates
execution of the function..." Actually, I think it's more correctly called
a "structured goto" because it doesn't terminate the function, it causes the
flow of execution to be transfered to the closing brace. And most
introductory courses in structured programs try and impress upon the student
that most programs that use "gotos" in any form, can usually be written
without them.

Just a matter of style perhaps, but it could just as easily be written:

{
...
if (!some_state) {
...
}
}

And IMHO it's clearer and easier to maintain.

--

Kaleb Keithley ka...@thyme.jpl.nasa.gov

Not authorized, in any way, shape, or form, to speak for anyone.

Tom Leylan

unread,
May 11, 1992, 7:45:43 PM5/11/92
to
In article <1992May10.1...@wyvern.twuug.com> al...@wyvern.twuug.com (Joe Wright) writes:
>
>The use of 'return' in this sense is probably harmless, but useless.
>All functions return to the caller. The 'return' statement is used
>to return a value or to quit executing before the end of a function,
>for example:

Joe:

"Probably harmless" ? I'm willing to use the word "harmless", there are
no ill effects. "Useless" on the other hand I'm not willing to concede.

Don't get me wrong I'm not suggesting that anybody change I'm simply asking
people which method they use. Most email replies (by far) indicate that
people do NOT add the return statement. A few (very few) say they do and
I'm just one of them. Sometimes I even put extra parentheses around
equations that don't require them... it is a readability issue and helps
prevent silly errors from occurring when I modify the expression.

I'm a self-proclaimed "an ounce of prevention is worth a pound of cure"
type programmer.

tom

Dave Eisen

unread,
May 11, 1992, 8:49:02 PM5/11/92
to
In article <1992May11....@pegasus.com> tle...@pegasus.com (Tom Leylan) writes:
>Don't get me wrong I'm not suggesting that anybody change I'm simply asking
>people which method they use. Most email replies (by far) indicate that
>people do NOT add the return statement. A few (very few) say they do and
>I'm just one of them. Sometimes I even put extra parentheses around
>equations that don't require them... it is a readability issue and helps
>prevent silly errors from occurring when I modify the expression.
>
>I'm a self-proclaimed "an ounce of prevention is worth a pound of cure"
>type programmer.

You've said this same thing several times now. And if you want
to write superfluous statements, who am I to stop you?

But I consider myself to be an aoopiwapoc type of programmer as well
and I don't see why omitting a return at the end of a void function
disqualifies me.

Unnecessary statements make code *less* readable. Maintenance programmers
look at them and scratch their heads and ask what the hell they
are doing there.

Now I wouldn't put the end-of-void-function return in that category
because it is *obvious* that it doesn't do anything. Especially since
you do it consistently. But I still don't see how it improves
readibility or makes maintenance any easier at all.

--
Dave Eisen dke...@leland.Stanford.EDU Sequoia Peripherals: (415) 967-5644
There's something in my library to offend everybody.
--- Washington Coalition Against Censorship

Ian Lepore

unread,
May 12, 1992, 4:19:36 AM5/12/92
to

>> return; at the end of a void function, where it isn't syntactically
>> required.

> Maintenance programmers look at them and scratch their heads ...
> But I still don't see how it improves readability or makes
> maintenance easier.

Well, I've been a primarily-maintenance programmer for 16 years now.
For the past 3 years, I've been making my living doing maintenance on
C code. I do probably 90% maintenance to 10% original coding.

As a maintenance programmer, I much prefer to have the so-called
"unneeded" return statements at the end of a void function. If nothing
else, it serves one very useful purpose: When I'm working on a function
that's longer than one screenfull of code, it's common that one of the
first things I do is search for return statements, to see if "early-outs"
in the logic have any bearing on the change I'm about to do. If the
function doesn't end with a return statement at the bottom, the search
operation in the editor goes down into the some other function later
in the code and finds a return statement there instead. Most unhandy.

- Ian

Georg Wittig

unread,
May 12, 1992, 4:12:38 AM5/12/92
to

>Just a matter of style perhaps, but it could just as easily be written:
>
>{
> ...
> if (!some_state) {
> ...
> }
>}
>
>And IMHO it's clearer and easier to maintain.

Maybe in that case, but it is NOT "clearer and easier" when you have 2 for
loops, a switch, and an if open. In the latter case you need an explicit
return statement to have "clear and easy" code.
--
"Freedom's just another word | Georg Wittig GMD-I8.IT P.O.Box 1316
for nothing left to lose" | D-W-5205 Sankt Augustin 1 (Germany)
| email: wit...@gmdzi.gmd.de
(J. Joplin, K. Kristofferson) | telephone: (+49) 2241 14-2294

D'Arcy J.M. Cain

unread,
May 12, 1992, 2:38:04 PM5/12/92
to
wit...@gmd.de (Georg Wittig) writes:
>>{
>> if (!some_state) {

>>And IMHO it's clearer and easier to maintain.
>Maybe in that case, but it is NOT "clearer and easier" when you have 2 for

I would say in any case it is clearer to return immediately if that is
what is happening conceptually. That is:

if (some_state)
return; /* we don't need to do anything else */
...

This seems cleaner and clearer than requiring someone to find the closing
brace of the "if (!some_state)" expression and make sure that nothing
else happens between that and the end of the function.

Tom Leylan

unread,
May 12, 1992, 11:13:39 PM5/12/92
to
In article <1992May12.0...@leland.Stanford.EDU> dke...@leland.Stanford.EDU (Dave Eisen) writes:
>
>But I consider myself to be an aoopiwapoc type of programmer as well
>and I don't see why omitting a return at the end of a void function
>disqualifies me.

Dave, I don't make the rules so you aren't "disqualified" no matter what
you do.

The replies are running about half and half now with 50% writing they
"always do". Please consider that all these types of readability issues
are personal, just as many programmers HATE Hungarian notation (which I
also recommend) many don't see readability increase with superfluous
return statements. Some think comments get in the way also.

If it helps me with my code then it is a good idea, while a style that
other programmers like would help in some ways it won't help at all if
I don't finish my projects and it has no effect if no other programmer
sees my code.

In any case, I'll add up the replies and post a final message and we don't
have to be concerned about it any longer.

tom

Tom Leylan

unread,
May 13, 1992, 6:21:18 AM5/13/92
to
In article <wittig.7...@gmd.de> wit...@gmd.de (Georg Wittig) writes:
>In <1992May11....@thyme.jpl.nasa.gov> ka...@thyme.jpl.nasa.gov (Kaleb Keithley) writes:
>
>>And IMHO it's clearer and easier to maintain.
>
>Maybe in that case, but it is NOT "clearer and easier" when you have 2 for
>loops, a switch, and an if open. In the latter case you need an explicit
>return statement to have "clear and easy" code.

Georg... Kaleb sort of changed subjects in mid-message so if you want to
start the age old rivalry about "multiple exit points" perhaps you should
start another thread. It's also not C-specific.

tom

Tom Leylan

unread,
May 13, 1992, 6:36:09 AM5/13/92
to
In article <FISCHER.92...@frigg.iesd.auc.dk> fis...@iesd.auc.dk (Lars Peter Fischer) writes:
>
>Why waste lines stating the obvoius? Should we add a few "x = x;"
>lines, too? More lines means more code to read, noting else.

Lars... just ran across your message (something's goofy with my reader)

The answer is "NO" we shouldn't add a few "x = x;" lines as that serves
no purpose and generates code. My return statement makes my code more
readable to me and doesn't generate additional code.

I mean, you're not from Aarhus are you ?

Hvor den har du det ?

tom

Jochen Linz

unread,
May 13, 1992, 8:14:04 AM5/13/92
to
In <1992May10.1...@pegasus.com>, Tom Leylan writes:
] [...]
]I've gotten a few email responses and you're in the majority but (in my

]view "thankfully") I'm not alone in "always doing it".
]
i'm always doing it,too

'cause :

1. it's a good style of structured programing
2. lint does check it
3. i've heard, without `return;' some (bad ?) compilers won't clear the stack

jochen

--

|featuring the massive, epoch-making humungous pangalactic, really quite large|
:-)---------------------------- mega-signature : ---------------------------(-:
| Jochen Linz Henckellweg 7 W-3000 Hannover 91 Germany, Voice: +49 511 417407 |

Richard J Brooks

unread,
May 13, 1992, 3:16:15 AM5/13/92
to
>>
>>The use of 'return' in this sense is probably harmless, but useless.
>>All functions return to the caller. The 'return' statement is used
>>to return a value or to quit executing before the end of a function,
>>for example:
>
> "Probably harmless" ? I'm willing to use the word "harmless", there are
> no ill effects. "Useless" on the other hand I'm not willing to concede.
>

Gentleman:

As sited in an earlier posting, it is not alway "harmless" not to add
an return at the end of a function. As sited, I to have run into compiler
that do interesting thing if a return is not there.

Therefore, adding a return at the end of function is good program
practice.


-----------------------------------------------------------------------------
Richard J Brooks | To know wisdom and instruction
Brooks%EWSVAX...@MDCGWY.MDC.COM | To discern the saying of understanding
| Proverbs 1:2
-----------------------------------------------------------------------------

David P. Murphy

unread,
May 12, 1992, 4:46:34 PM5/12/92
to

>If you're getting paid by the lines of code, add the return, but it's both
>superfluous and redundant :-), and maybe it shows you don't really under-
>stand the language.
>
>ka...@thyme.jpl.nasa.gov (Kaleb Keithley)

gimme a break. a return at the end of a void function illustrates that
the author definitely intended that point to be the end of the function.

besides, it's handy to be able to search for "return" in *any* function
and know that you'll find all of the exit points.

ok
dpm
--
mur...@npri6.npri.com 602 Cameron St. Alexandria, VA 22314 (703) 683-9090

When every one is dead the Great Game is finished. Not before.
--- Hurree Babu, "Kim"

Message has been deleted

Lars Peter Fischer

unread,
May 13, 1992, 9:55:13 PM5/13/92
to
>>>>> "Richard" == Richard J Brooks (bro...@ewsvax.mdcbbs.com)

Richard> As sited in an earlier posting, it is not alway "harmless"
Richard> not to add an return at the end of a function. As sited, I
Richard> to have run into compiler that do interesting thing if a
Richard> return is not there.

Then it's not a C compiler. By the same argument you would have to
avoid recursion because there are compilers that are broken and cannot
handle it. And don't use structs or arrays, there are probably
compilers that have trouble with that.

Richard> Therefore, adding a return at the end of function is good program
Richard> practice.

Is it good practice to clutter your code to defend against broken
software? Why not get another compiler?

Lars Peter Fischer

unread,
May 13, 1992, 10:03:00 PM5/13/92
to

>>>>> "Tom" == Tom Leylan (tle...@pegasus.com)

Tom> The answer is "NO" we shouldn't add a few "x = x;" lines as that serves
Tom> no purpose and generates code.

They do? I would hope that my compiler is more intelligent than that.

Tom> My return statement makes my code more readable to me and
Tom> doesn't generate additional code.

Yes, that's what I'm after -- I know quite well that a function call
returns at the end of a function. Putting a return statement there
just makes for yet a line I have to read. It's a bit like

counter++; /* increment the counter */

Tom> I mean, you're not from Aarhus are you ?

Well, actually I am, but I don't live there any more. :-)

Tom Stockfisch

unread,
May 14, 1992, 1:43:56 AM5/14/92
to
In article <1992May9.0...@dartvax.dartmouth.edu> cr...@coos.dartmouth.edu (Preston F. Crow) writes:
>In <1992May8.2...@pegasus.com> tle...@pegasus.com (Tom Leylan) writes:
>What do people think about the explicit use of a return statement in a
>function that returns void ?
>void test()
>{
> /* some code */
> return;
>}

/* beginning of article */

This is good as far as it goes, and is certainly safer than running directly
into the final right brace. I, however, use _two_ returns, like this:

void test()
{ /* begin body of test */
...
return;
return;
} /* end body of test */

That way, if the reader happens to miss the first "return" he almost
surely will notice the second and pause to consider all the ramifications
of not returning a value from a void function. In addition, if I
accidently remove one of the returns the other return is still there,
adding a nice safety margin for code reliability.

Along this same line I also add an extra ";" at the end of expression
statements to emphasize that these are complete statements.
Example:

while (i < n)
{
x[i] = y[i];;
++i;;
}

Now, you might say that the extra ";" will mess up "if...else" sequences.
To that objection I would respond, why on earth are you not surrounding
all of the code controlled by an "if" with braces? There is no excuse for
writing the dangerous

if (condition)
statement;

when you can just as easily write

if (condition)
{
statement;;
}

If my "while" loop is in a particularly crucial part of the code I will
write it as

while (i < n && !(i >= n))
{
x[i] = y[i];;
x[i] = y[i];;
++i;;
}

This emphasizes to the reader what the loop invariant is, making him
think about it in two different ways, and also guarantees that the
assignment gets done, and that the reader notices for sure what gets
assigned to what.

If I actually do return a value from a function I use:

return( (1+2) );;

The first set of parentheses is to make "return" look like a function call,
which I like a lot, and the second is, again, a safety factor -- If later
I should add to the expression, as in

return( (1+2)*2 );;

Then I don't have to worry about the "*" binding to the wrong object.


/* end of article */
/* end of article */

[Just in case, :) :)]

"brevity is the essence of wit"

"if two nails will probably hold it together, 100 nails will _surely_ hold
it together"
--

|| Tom Stockfisch, UCSD Chemistry t...@chem.ucsd.edu

Tom Stockfisch

unread,
May 14, 1992, 1:45:29 AM5/14/92
to
In article <1992May10....@druid.uucp> da...@druid.uucp (D'Arcy J.M. Cain) writes:
>tle...@pegasus.com (Tom Leylan) writes:

>void foo(int x) /* I'll create a function here one day */
>{
> return;
>}
>
>Sort of draws my attention to incomplete code.

How about

void
foo(x)
int x;
{
assert(0);

Jan Christiaan van Winkel

unread,
May 14, 1992, 4:03:49 AM5/14/92
to
In <usums...@network.ucsd.edu> t...@chem.ucsd.edu (Tom Stockfisch) writes:
>This is good as far as it goes, and is certainly safer than running directly
>into the final right brace. I, however, use _two_ returns, like this:

>void test()
>{ /* begin body of test */
> ...
> return;
> return;
>} /* end body of test */

>Along this same line I also add an extra ";" at the end of expression


>statements to emphasize that these are complete statements.
>Example:

> x[i] = y[i];;

>If my "while" loop is in a particularly crucial part of the code I will
>write it as

> while (i < n && !(i >= n))
> {
> x[i] = y[i];;
> x[i] = y[i];;
> ++i;;
> }


======
TTTHHHIIISSS IIISSS AAA NNNOOONNN---IIITTTEEEMMM!!!!!!

IIInnn ttthhheee gggooooooddd ooolllddd dddaaayyysss,,,
ttthhheee UUUNNNIIIXXX mmmaaannnuuuaaalllsss aaalllrrreeeaaadddyyy
sssaaaiiiddd ttthhhaaattt yyyooouuu ssshhhooouuulllddd uuussseee
TTTHHHRRREEEEEE sssyyynnncccsss,,, bbbeeecccaaauuussseee
ooonnneee mmmiiiggghhhttt nnnooottt
mmmeee eeennnooouuuggghhh...
SSSooo ttthhhiiisss ppprrraaaccctttiiiccceee ooofff
ssstttaaatttiiinnnggg yyyooouuurrr iiinnnttteeennntttiiiooonnnsss
mmmuuullltttiiipppllleee tttiiimmmeeesss hhhaaasss
bbbeeeeeennn aaarrrooouuunnnddd fffooorrr qqquuuiiieee sssooommmeee
tttiiimmmeee nnnooowww...

JJJCCC
++++++

PS: for the vi impaired: take my message in vi and type
/======/,/++++++/s/\(.\)../\1/g
--
___ __ ____________________________________________________________________
|/ \ Jan Christiaan van Winkel j...@phoibos.cs.kun.nl
| Alternative e-mail addresses: j...@oreo.atcmp.nl and j...@atcmp.nl
__/ \__/ ____________________________________________________________________

Nick Ruprecht

unread,
May 14, 1992, 7:46:48 AM5/14/92
to
t...@chem.ucsd.edu (Tom Stockfisch) writes:

>How about

> void
> foo(x)
> int x;
> {
> assert(0);
> }
>--

How imperfect :-). What you want is of course:

/* Use fdopen() so we don't rely on "stderr" being defined.
* Use "do { ... } while(0)" to avoid the dangling else problem.
*/
#define NOTIMPLEMENTED do { \
fprintf(fdopen(2, "w"), \
"file %s, line %d: Function not implemented\n", \
__FILE__, __LINE__); exit(1); } while(0)

so you can do

foo()
{
NOTIMPLEMENTED;
}

and get some information as the program exits:

file foo.c, line 3: Function not implemented

P.S.: I prefer return's at the end of functions, but usually I forget ...

Regards,

--

Nick Ruprecht
Institut fuer Informatik der Universitaet Freiburg

Christopher R Volpe

unread,
May 14, 1992, 11:47:43 AM5/14/92
to
In article <55...@npri6.npri.com>, mur...@npri6.npri.com (David P. Murphy) writes:
|>
|> >If you're getting paid by the lines of code, add the return, but it's both
|> >superfluous and redundant :-), and maybe it shows you don't really under-
|> >stand the language.
|> >
|> >ka...@thyme.jpl.nasa.gov (Kaleb Keithley)
|>
|> gimme a break. a return at the end of a void function illustrates that
|> the author definitely intended that point to be the end of the function.

Gimme a break. The right brace illustrates that the author definitely intended


that point to be the end of the function.

|>
|> besides, it's handy to be able to search for "return" in *any* function
|> and know that you'll find all of the exit points.

Perhaps. I've never found it helpful to be able to do that.

-Chris

--
==================
Chris Volpe
G.E. Corporate R&D
vol...@crd.ge.com

Karl Heuer

unread,
May 14, 1992, 5:15:04 PM5/14/92
to
In article <H.VWFp...@krokus.han.de> jl...@krokus.han.de writes:
> 1. it's a good style of structured programing

That's an opinion. I happen to disagree.

> 2. lint does check it

Not any lint I've ever used. Perhaps you're thinking of non-void functions?
AT&T lint does have a warning about falling off the end without returning a
value, but it still doesn't distinguish between explicit and implicit return.

> 3. i've heard, without `return;' some (bad ?) compilers won't clear the stack

Jesus Coredumping Christ. Okay, I'll play it your way. I once heard of a
compiler where "return;" would branch back to the beginning of the function
instead of going back to the caller.

Karl W. Z. Heuer (ka...@ima.isc.com or uunet!ima!karl), The Walking Lint

Tom Leylan

unread,
May 14, 1992, 5:59:57 PM5/14/92
to

> i'm always doing it,too

Jochen...

Well that vote does it, the replies are 10 to 10, please see my summary
elsewhere in this newsgroup...

I worked in Munich for a while, did it there also <g>

tom

D'Arcy J.M. Cain

unread,
May 14, 1992, 3:24:56 PM5/14/92
to
bro...@ewsvax.mdcbbs.com (Richard J Brooks) writes:
>As sited in an earlier posting, it is not alway "harmless" not to add
>an return at the end of a function. As sited, I to have run into compiler
>that do interesting thing if a return is not there.
>
>Therefore, adding a return at the end of function is good program
>practice.

No, throwing away broken compilers is good programming practice.

Mike Schilling

unread,
May 15, 1992, 12:57:39 PM5/15/92
to
Another variant of Murphy's law: The silliest topics generate the
largest number of postings.
----------------------------------------------------------------------------
mi...@ingres.com = Mike Schilling, INGRES, An ASK Company, Alameda, CA
Just machines that make big decisions,
Programmed by fellows with compassion and vision. -- Donald Fagen, "IGY"

Tom Leylan

unread,
May 15, 1992, 7:56:57 AM5/15/92
to
(Lars Peter Fischer) writes:

>They do? I would hope that my compiler is more intelligent than that.

<and>

>Yes, that's what I'm after -- I know quite well that a function call
>returns at the end of a function. Putting a return statement there
>just makes for yet a line I have to read. It's a bit like
>
> counter++; /* increment the counter */

Lars... I was wrong about optimizing compilers and x = x; .

You don't have to read my extra returns, only I do and other people
whom I give the code to... you might write your comments in Danish
well how is that going to help some guy in Cleveland, Ohio ?

The interesting part of this study is only that the final, final tally
is 11 do to 10 don't so as flawed as it is we have at least put to rest
the idea that "everybody will think you're loony" or other pure guesses.

Please keep in mind it is only a question of preferences may as well
argue about whether tea or coffee is more hazardous to your health or
any of a dozen important topics.

Again, thanks.

tom

Dan Drake

unread,
May 19, 1992, 5:38:38 PM5/19/92
to
mi...@Ingres.COM (Mike Schilling) writes:
> Another variant of Murphy's law: The silliest topics generate the
> largest number of postings.
> ----------------------------------------------------------------------------
Yes, and when you see a silly topic, remember to skip to the last few
messages, because by the time you get up to reply # 30 of 37, the
discussion will have got completely goofy and may yield some gems worth
saving or sending to rec.humor.funny.

return ;;
return ;;
--
Dan Drake
dr...@Autodesk.com

Jens Tingleff

unread,
May 21, 1992, 4:46:27 PM5/21/92
to
In article <1992May15.1...@pegasus.com>, tle...@pegasus.com (Tom Leylan) writes:
> (Lars Peter Fischer) writes:
>

> The interesting part of this study is only that the final, final tally
> is 11 do to 10 don't so as flawed as it is we have at least put to rest
> the idea that "everybody will think you're loony" or other pure guesses.
>

NONONONO NO NO NO NO

[Serious mode on]

I think such a practices is really superfluous. Then again, I was brougt up on
Pascal and M-2 where the end is specifically marked (by name in M-2; superb).
These days I use C (sigh!), but compensates by using emacs which will show me
brace-mathing, giving me complete indication of the *actual* start-end of a
function rather than what the programmer thought..

[Serious off, late night silly on]

> Please keep in mind it is only a question of preferences may as well
> argue about whether tea or coffee is more hazardous to your health or
> any of a dozen important topics.

Come on, surely we can have a discussion about as vital a subject as this ;-)
For redundant postings in serious groups, this doesn't even begin to reach the
levels attained in the discussion on comp.unix.bsd on whether it was OK to write
(in a technical document) that <insert favourite ethnic group> knew the best
<ethnic group native> restaurants.

Jens

--
Mr Jens Tingleff, M.Sc.EE. PhD student at
Imperial College, Dept of EE, Exhibition Road, London SW7 2BT, England
jens...@titan.ee.ic.ac.uk or jens...@ee.ic... (used to be jens...@diku.dk)
S: "David, stop rocking from side to side" D: "SUSAN!" 'Bringing up Baby'

Reply all
Reply to author
Forward
0 new messages