Re: [open-cobol-list] procedure division returning

[Frank Swarbrick]

Hi Sergey,

That works in a limited fashion, but still has some issues.  Issue #1:

14.1 Procedure division structure
14.1.1 General format
where procedure-division-header is:
PROCEDURE DIVISION [ using-phrase ] [ RETURNING data-name-2 ]

14.1.2 Syntax rules
5) Data-name-2 shall be defined as a level 01 entry or level 77 entry in the linkage section.
("in the linkage section" highlighted by me)

With your change the returning data item must be in the working-storage section.  (It doesn't even work if declared in the local-storage section.)

I've been looking at how IBM mainframe COBOL solves this issue.  It appears that if the returning data item is a non-group item the compiler automatically allocates stack storage for it (within the called routine) and then, in essence, does a "return" of that.  Seems like a reasonable way to do it.

Now if the returning data-item is a group data item, array, or string (really any item that cannot be returned in a register), the caller implicitly passes a reference to the return item as parameter 1, and the callee directly modifies the value at that location.  So, basically, the following two statements function in the same manner:

call 'callee' using by reference string-out string-in
call 'callee' using by reference string-in returning string-out

similarly, these are the same:

program-id. 'callee'.
data division.
linkage section.
01  output-string                          display   pic x(80).
01  input-string                             display   pic x(80).
procedure division using by reference output-string, input-string.
    move function reverse(input-string) to output-string
    exit program.

program-id. 'callee'.
data division.
linkage section.
01  output-string                          display   pic x(80).
01  input-string                             display   pic x(80).
procedure division using by reference input-string returning output-string.
    move function reverse(input-string) to output-string
    exit program.

and a C call to either would be something like this:
char output_string[80], input_string[80];
callee(output_string, input_string);
if the parms were structs the call would be something like
callee_struct(&out_struct, &in_struct);

I got a little sidetracked on the second point, but the first point has another issue.  It seems only to work with integer (comp/binary) parameters, but not with float/double (float-short, float-long) parameters.  See the following example:

local-storage section.
77  double-in                           comp-2 value 2.
77  double-out                          comp-2.

    call static 'cobatan2' using value double-in returning double-out

  /* Line: 18        : CALL               : ret_test2.cob */
  {
    {
      module.cob_procedure_params[0] = (f_5.data = "" + 0, &f_5);
      memset (&(module.cob_procedure_params[1]), 0, 32);
      cob_glob_ptr->cob_call_params = 1;
      (*(int *) (b_1)) = cobatan2 (*(double *)(cob_local_ptr + 0));
      cob_set_int ((f_6.data = "" + 16, &f_6), (*(int *) (b_1)));
    }
  }

Here the input parameter is properly cast to a pointer to a double, but the return value is treated as a pointer to an integer.  I'm not at all sure, but I would imagine the last lines should be something to the effect of this:
      (*(double *) (b_1)) = cobatan2 (*(double *)(cob_local_ptr + 0));
      cob_set_double ((f_6.data = "" + 16, &f_6), (*(double *) (b_1)));
And of course b_1, which is the "return-code special register" needs to be large enough to hold a double (8 bytes instead of 4).  Or use the actual variable directly.

Are you by chance able to see if this issue is resolved in OC 2.0?  I thought I'd read that 2.0 has user defined functions, and if it does it seems to me they would have had to solve this issue.

Frank









On 6/29/2013 4:29 AM, Sergey Kashyrin wrote:

http://www.kiska.net/opencobol/1.1/index.html

On 6/29/2013 12:39 AM, Frank Swarbrick wrote:

Well that's cool (and very fast!).  I don't suppose there's any way I can get this fix....?

On 6/28/2013 1:43 AM, Sergey Kashyrin wrote:

Hi Frank,

Just checked and can confirm that in 1.1 (all subversions) PROCEDURE DIVISION RETURNING was not implemented correctly yet.
I've fixed that in my 1.1 version.

Regards,
Sergey

On 6/28/2013 2:53 AM, Frank Swarbrick wrote:

ret_test.cob:48: Error: RETURNING item is not defined in LINKAGE SECTION

On 6/28/2013 12:47 AM, Sergey Kashyrin wrote:

Hi Frank,

It is not suppose to work. I mean it works exactly as expected, i.e. SEGFAULT
"len" is declared in linkage section and not referenced in "using", and that mean it is not allocated.
Referencing in "returning" does not allocate the memory for variable.
Move it to working or local storage and everything will be fine.

Regards,
Sergey

On 6/28/2013 1:35 AM, Frank Swarbrick wrote:

Anyone ever got this to work?
Take a look at this:

       >>SOURCE FORMAT IS FREE

program-id. caller.
data division.
local-storage section.
77  str-len  binary-long.
procedure division.
    call 'callee1' using content 'This is a test'
         returning str-len
    display str-len
    call 'callee2' using content 'This is a test!'
         returning str-len
    display str-len
    goback.
end program caller.

program-id. callee1.
data division.
linkage section.
01  str  pic x any length.
procedure division using str.
    compute return-code = function length(str)
    exit program.
end program callee1.

program-id. callee2.
data division.
linkage section.
01  str  pic x any length.
01  len  binary-long.
procedure division using str returning len.
    compute len = function length(str)
    exit program.
end program callee2.

callee1 works fine.  callee2 causes a core dump or some such thing.

Looking at the generated C code I see the following:

/* PROGRAM-ID : callee1 */
static cob_u8_t b_8[4];    /* RETURN-CODE */

/* PROGRAM-ID : callee2 */
static cob_u8_t b_14[4];    /* RETURN-CODE */


/* PROGRAM-ID : callee1 */
static cob_field f_8    = {4, b_8, &a_3};    /* RETURN-CODE */
static cob_field f_12    = {1, NULL, &a_1};    /* str */

/* PROGRAM-ID : callee2 */
static cob_field f_18    = {1, NULL, &a_1};    /* str */
static cob_field f_19    = {4, NULL, &a_2};    /* len */

/* LINKAGE SECTION (Items not referenced by USING clause) */
static unsigned char    *b_19 = NULL;  /* len */


The compute in callee1:
    cob_decimal_set_field (&d0, cob_intr_length (&f_12));
    cob_decimal_get_field (&d0, &f_8, 0);

The compute in callee2:
    cob_decimal_set_field (&d0, cob_intr_length (&f_18));
    cob_decimal_get_field (&d0, (f_19.data = "" &f_19), 0);

So what's happening is that in callee2 variable 'b_19', which is the address of the COBOL field 'len' is still set to NULL, and thus we get a null pointer exception when trying to set it.

So it seems to me that even though the returning clause of the procedure division is allowed syntactically its not actually supported in the run-time.  Bad news!  :-(

Interestingly, a small kludge will make it work.  I added the following before any attempt to use the returning field (len):
    set address of len to address of return-code

And now it works.

Comments?

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list