× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: ILE bug or "feature"?
  • From: "M. Lazarus" <mlazarus@xxxxxxxx>
  • Date: Tue, 06 Feb 2001 20:06:01 -0500

Doug,

At 2/6/01 07:16 PM -0500, you wrote:
>Since the CLLE program XTEST did not prototype the call to TEST2, there is no
>parameter checking -- just like in OPM.

  I'm not looking for COMPILER verification, just runtime verification.

>Think for a minute what you'd expect if all the programs OPM.  Would you still
>be surprised?  That is in essence what you have here since you don't have
>prototypes on both sides to validate parameter definitions.

  I *would* be surprised.  To test this I changed the CALLPRC statements to 
CALLs.  I compiled the RPGLE's into *PGMs.

     pgm

     dcl    &p1 *char 9    'abcdefghi'
     dcl    &p2 *char 7    '1234567'
     dcl    &p3 *char 1    'A'
     dcl    &p4 *char 10   'QRSTUVWXYZ'
     dcl    &p5 *char 3    '987'

     call   z11 parm( &p1 &p2 &p3 &p4 &p5 )

     call   z22

endpgm


  I made one minor change (the EVAL in the calcs) so the variable would be 
referenced.  When I did this in the bound program it did not give me an 
error, which I think is incorrect behavior.

  D P1              S              9
  D P2              S              7
  D P3              S              1
  D P4              S             10
  D P5              S              3

  C     *ENTRY        PLIST
  C                   PARM                    P1
  C                   PARM                    P2
  C                   PARM                    P3
  C                   PARM                    P4
  C                   PARM                    P5

  C                   EVAL      P1 = P1

  C                   SETON                                        LR
  C                   RETURN

  Sure enough, as I thought, an error was generated.

  Message ID . . . . . . :   RNQ0222       Severity . . . . . . . 
:   99
  Message type . . . . . 
:   Inquiry
  Date sent  . . . . . . :   02/06/01      Time sent  . . . . . . 
:   19:47:46

  Message . . . . :   Pointer or parameter error (C G D 
F).
  Cause . . . . . :   RPG procedure XTEST2 in program MARK/XTEST2 at 
statement 14
    had an error due to a pointer not being correctly set. The cause of 
the
    error is most likely one of the 
following:
      -- A basing pointer was not 
set.
      -- A procedure pointer was not 
set.
      -- The pointer was set, but the object it referenced has been 
destroyed.
      -- A parameter was not passed to the program containing the 
procedure.
      -- A parameter was not passed to the procedure by its caller within 
the
    program. 

      -- A pointer offset was greater than the size of the space the 
pointer was pointing to.


> >or the variables should have been cleared.

>I presume what you mean is you think the call stack should have been cleared.

   I say that the pointer should have been destroyed.

> >2)  In an ILE environment, where a module is supposed to be designed for
> >reuse, this is an entirely possible scenario.
>
>Prototypes guard against mismatched parameters -- assuming the prototypes are
>correct.

  CLLE's can't be prototyped.  I expect similar behavior between ILE and 
OPM programs when doing non-prototyped calls.  Again, I'm referring to 
runtime, not compiler checking.


  -mark

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.