RETURNING items of User-Defined FUNCTIONs - WORKING-STORAGE or LINKAGE items?

GnuCOBOL
2014-01-02
2014-01-07
  • Simon Sobisch

    Simon Sobisch - 2014-01-02

    I've uncovered a bug in cobc's codegen when working on a test case for a different UDF bug.

    In my opinion (but I'm currently out of documentation) RETURNING items of UDF should be places in WORKING-STORAGE as it is returned, but not passed by the caller.

           IDENTIFICATION   DIVISION.
           FUNCTION-ID.     WITHPAR.
           DATA             DIVISION.
           WORKING-STORAGE  SECTION.
           01 PAR-OUT       PIC 9.
           LINKAGE          SECTION.
           01 PAR-IN        PIC 9.
           PROCEDURE DIVISION USING PAR-IN RETURNING PAR-OUT.
               ADD 1 TO PAR-IN GIVING PAR-OUT END-ADD.
               GOBACK.
           END FUNCTION WITHPAR.
    

    Currently this code leads to a C compiler error (see [#57], where I've posted a quick-fix [just tested with a simple program]) which is surely a bug. Either there is a clear definition that WORKING-STORAGE items are not allowed there (which I don't think) and cobc should throw an error or items in LINKAGE-STORAGE should not be used [or be self-allocated] and we should simply delete the whole code part.
    Or we use the supplied patch (tweak it if possible) and supporting both.

    What do you think of this issue? Do you have any docs for UDF you can quote where RETURNING items should be located and/or samples [despite of the samples here in this board]?
    Do you have any suggestions for a better patch?

    Simon

     

    Related

    Bugs: #57

  • Edward Hart

    Edward Hart - 2014-01-03

    I think the continue on line 18 of the patch would be better replaced with a break.

     
    • Simon Sobisch

      Simon Sobisch - 2014-01-04

      Sure, but maybe not needed any more, as the discussion evolves.

       
  • Brian Tiffin

    Brian Tiffin - 2014-01-04

    Yeah, Simon; we have a fair boat load of debugging with FUNCTION-ID additions. The current compiler is leaking like a sieve. Both on CALL and FUNCTION.

    On topic; RETURNING items are LINKAGE by spec (13.7 in the draft 20xx (not 2009, the current almost final candidate) and 14.2.3).

    User defined function run time support has to be in charge of the RETURNING allocation, as UDFs need to provide anonymous COBOL fields, which in an expression may never involve working storage.

    And there are bugs, more than one. The 2.0 codebase started out as a Roger work in progress, and we have a fair number of

    /* RXW */
    

    tags to grep through.

    valgrind complains loudly, both with the compiler and with the generated executables. But; valgrind also shows where to look; for the win.

    Cheers,
    Brian

     
    Last edit: Brian Tiffin 2014-01-04
  • Simon Sobisch

    Simon Sobisch - 2014-01-04

    After reading the specs again I think we should issue an error if RETURNING items are in WORKING-STORAGE - for both FUNCTIONs and PROGRAMs (see [#58]) and therefore always allocate the storage of RETURNING items (which currently leads to a compiler error of GCC when an item of WORKING-STORAGE is used).
    Any objections/confirmations?

    Is anybody there supplying a patch for the compiler error?

    Simon

     

    Related

    Bugs: #58

  • Bill Woodger

    Bill Woodger - 2014-01-07

    IBM Enterprise COBOL has a RETURNING on the PROCEDURE DIVISION. It must be defined in the LINKAGE SECTION. Until set by the called program, its value is undefined, ie it does not address the matching field on the RETURNING on the CALL in the calling program, data cannot be passed to the caller using the RETURNING field. It is an IBM Extension, to the '85 standard, but presumably encapsulates their understanding of what RETURNING would be in a new Standard.

    Basically I think IBM's treatment agrees with what I understand your understanding to be Simon :-)

     
    Last edit: Bill Woodger 2014-01-23

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks