Announcement

Collapse
No announcement yet.

RETURN with no GOSUB

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Cecil Williams
    Guest replied
    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

    Leave a comment:


  • Michael Mattias
    replied
    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]

    Leave a comment:


  • Cecil Williams
    Guest replied
    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

    Leave a comment:


  • Chris Boss
    replied
    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.

    Leave a comment:


  • Eric Pearson
    replied
    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).]

    Leave a comment:


  • jcfuller
    replied
    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

    Leave a comment:


  • Eric Pearson
    replied
    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...

    Code:
    '(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).]

    Leave a comment:


  • Don Dickinson
    replied
    confirmed GPF in pbdll6 and pbcc2
    Best Regards,
    Don

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

    Leave a comment:


  • jcfuller
    started a topic RETURN with no GOSUB

    RETURN with no GOSUB

    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


    Code:
    #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
Working...
X