Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!apple.com!desnoyer
From: desnoyer@apple.com (Peter Desnoyers)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Spurious Turbo-C warning -- how do I get around it?
Message-ID: <4216@internal.Apple.COM>
Date: 18 Sep 89 19:23:46 GMT
Sender: usenet@Apple.COM
Distribution: usa
Organization: Apple Computer, Inc.
Lines: 49
References:<5554@videovax.tv.Tek.com> <6913@stiatl.UUCP>

In article <6913@stiatl.UUCP> tom@stiatl.UUCP (Tom Wiencko) writes:
> In article <5554@videovax.tv.Tek.com> dougs@videovax.tv.Tek.com (Doug 
Stevens) writes:
> >>I'm trying to figure out how to get around a 'feature' of Turbo-C. 
> >>      #define TRUE    1
> >>      int test(void)
> >>      {
> >>              while (TRUE) {
> >>                      return(1);
> >>              }
> >>      }
> >> ...
  [error msg. is "function does not return a value"]
> >>Anyone figured out a way around this?

For years people have been writing things like:
  foo{
    while (1) return (0);
    return (0); /* to please lint */}

The problem is that lint (or Turbo C - or any computable program) can't 
figure out that you never drop through the bottom of the loop. This is 
best dealt with by putting in a return statement that will never be 
executed.

> Sure... don't return out of the middle of a loop.  
> A properly structured subroutine has ONE entry point and ONE exit point

I would not expect such dogma from someone programming in a heathen 
language such as C. In realistic usage it is often much cleaner, easier to 
read, and easier to maintain if multiple exit points are used. For 
instance, if an error early in a routine requires an exit after a 
different clean-up sequence than at the end of the routine, your code is 
going to be a lot cleaner if you use two return statements.

> In general, warnings like this are there to tell you that you are writing
> code which is not well structured, or is not properly taking advantage
> of the appropriate C idioms.

Single return per function is definitely NOT a C idiom. Always returning a 
value from a function declared to return a value is not just C idiom, but 
good (almost necessary) programming practice in any language. Having to 
put in spurious return statements due to the inability of lint (or 
lint-equivalent) programs to compute the halting problem is also a C 
idiom, for better or worse.

                                      Peter Desnoyers
                                      Apple ATG
                                      (408) 974-4469