RETURN with no GOSUB

[jcfuller]

Would someone test and confirm a gpf with the following code.
It appears the complier is miising the fact there is a RETURN with no
prior GOSUB.

James

#COMPILE EXE
#DIM ALL
'---------------------------------------------------------------------------
FUNCTION _
  TestIt ( _
    BYVAL Var1		AS LONG _
  ) AS LONG
  
  DIM L1		AS LONG
  
  
  L1 = 44

'compiler misses RETURN without  GOSUB
  RETURN  
  
END FUNCTION    
'---------------------------------------------------------------------------
FUNCTION _
  PBMain ( _
  ) AS LONG
  
  TestIt 22
  
END FUNCTION

[Don Dickinson]

confirmed GPF in pbdll6 and pbcc2
Best Regards,
Don

[This message has been edited by Don Dickinson (edited January 21, 2000).]

[Eric Pearson]

James --

> a RETURN with no prior GOSUB.

That would be a very difficult thing for the compiler to detect, so I'm not surprised that it doesn't. For example, the following code, while very poorly written, is perfectly legal and should (IMO) be allowed to compile...

'(other code)
GOSUB MyGosub
 
EXIT FUNCTION
 
AllDone:
   '(do something)
   RETURN
 
Oops:
   '(do something else)
   RETURN   
 
MyGosub:
   '(do something)
   IF X% <> 0 THEN GOTO Oops ELSE GOTO AllDone
 
MyOtherGosub:
   '(do something)
   IF X% <> 0 THEN GOTO Oops ELSE GOTO AllDone

That may not be an ideal example, but you get the idea. Each GOSUB can have one or more RETURNS, you could (at least theoretically) have two GOSUBs that share one RETURN... it would be a very complex thing for the compiler to have to figure out for you. I suppose that runtime error detection might be possible (RETURN WITHOUT GOSUB or some such) but that would impose a speed penalty. And what would you do if ERR was set by that error? You'd probably want your program to halt, since it would not know what code to execute next (program flow errors are very hard to handle at runtime)... so maybe a GPF is the best thing it can do. {G}

-- Eric

-------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited January 21, 2000).]

[jcfuller]

Eric,
The point is there are "NO" GOSUB's so there will never be a vaild return
address on the stack.

I happened by this by accident cutting and pasting a GOSUB/RETURN to a FUNCTION
and copied the RETURN along with the code.
James

[Eric Pearson]

James --

Understood, but if the compiler could only detect RETURN WITHOUT GOSUB some of the time, and it let it go undetected most of the time, IMO it would be of little value. If the error was added to the compiler, I think there would be an expectation on the part of users that it would detect all such errors. Just my opinion.

-- Eric
-------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited January 21, 2000).]

[Chris Boss]

JCFuller;

Eric is right!

The compiler would have a tough time "weeding" this one out.

I find that if I create a Function or Procedure which "may" contain a gosub and return in it, I always use the following format:

ie.

Function MyFunction(....) as Long

' my functions code
' with possible gosubs

FUNCTION=SomeValue&
Exit Function

AnyLabel:

Return

AnotherLabel:

Return

End Function

By putting the Exit Function (or Exit Sub) before "any" defined routines that will be called by a gosub, you prevent any "slip throughs" to the code beyond the exit command.

While it is true that you could be cutting and pasting and then remove a gosub routine and forget to remove the return, the Exit Function is still in place and would prevent any problems.

The likely hood of accidently adding a return is slim, but the problem is when you have a gosub routine and you delete it and forget to remove the return.

[Cecil Williams]

Hi Mr. Fuller,

I think the problem was due to the "RETURN" being located inside a
function rather than a subroutine. A single "RETURN" inside a function
definition apparently means nothing to the compiler. However, had that
ocurred inside a subroutine, the procedure would have just returned to
the point where the sub was invoked. Same as calling EXIT SUB. But this
is something I'm sure you're well aware of. The compiler should have
flagged this as some sort of anomaly at least when located in a function
definition. A "WARNING", if you will!!!!!

That's why I make it a practice to explicitly declare all procedures and
avoid using GOTO or GOSUB calls. Makes for a little more programming but
the procedure is done if needed in the future on a different project. No
cut and paste, just minor editing.

Cheers,
Cecil

[Michael Mattias]

I have been known to be a "stickler" on the compiler missing things (if not that, surely I've been equated to a pain in some body part), but coding a RETURN - a perfectly valid verb - and expecting the compiler to detect the absence of a GOSUB in the source code and all $INCLUDEd files is more than even I would ask.

If you can have multiple RETURNs within a labelled subroutine, should the compiler tell you you have *excess* RETURNs? I'd find that more offensive than Microsoft Word's (r) "grammar checker." (Which, in my view, can't handle a whole lot beyond eighth grade without telling me my sentences are 'too complex.' What does that tell you about the authors?)



-------------
Michael Mattias
Racine WI USA
[email protected]

[Cecil Williams]

Hi Michael,

I understand your sentiments, however IMHO you missed the point. The
"RETURN" was located inside a function definition not a subroutine. I
agree that you could have a thousand "RETURN"s inside a sub, these are
two different animals. Makes for a programming nightmare especially if
you did not write the code and are trying to read it.

The "RETURN" located in the function apparently corrupted JC Fuller's
procedure pointer, thus a GPF ensued. That's why I EXPLICITY avoid
GOTO and GOSUB calls. Just a matter of coding style, as everyone has.

Cheers,
Cecil