#58 PROGRAM RETURNING items are not allocated.

[Edward Hart]

The following program causes a segfault when called as the returning item is not allocated and has a NULL address.

:::cobolfree
PROGRAM-ID. foo.
DATA DIVISION.
LINKAGE SECTION.
01  num                                 PIC 9(5).
PROCEDURE DIVISION RETURNING num.
    MOVE 1 TO num
    .
END PROGRAM foo.

[Simon Sobisch]

This corresponds to [08d8b633] / [#57]. Do you have any docs that state "RETURNING items should reside in LINKAGE SECTION"? My thought was always that they should be in WORKING STORAGE.
This works for "normal" programs and will work for user-defined functions (UDF), too, after my patch is applied. If we remove the line 6279 in codegen.c (2.x trunk) it will work for normal programs too, but I'd like to see some docs and discussion before...

Simon

[Edward Hart]

Do you have any docs that state "RETURNING items should reside in LINKAGE SECTION"?

From the 2009 Draft COBOL standard (14.2.2.5): '[The RETURNING item] shall be defined as a level 01 entry or level 77 entry in the linkage section'. Furthermore, the Micro Focus docs suggest that the Micro Focus and IBM compilers enforce this (Syntax Rules - 4 and General Rules - 8).

This corresponds to [08d8b633] / [#57].

Sorry about the duplicate - it would probably be best if you close this bug report and we carry on any discussion in [#57].

[Edward Hart]

Still present as of [r1524].

[Simon Sobisch]

We may come back to this with the external repository implementation...

[Simon Sobisch]

Ed, thank you for the reference in the duplicate bug report.
The RETURNING item is definitely correct in the LINKAGE and therefore needs the allocation check generated with -debug even inside the internal parts (should be no big deal). The much more important point is that the caller "assumes" the RETURNING item that he specifies (otherwise you'd allways have a missing allocation) is just used as internal move of the RETURN-CODE value (without changing it in the caller, if I remember correctly) which matches a long-standing extensions (MF/ACU, likely others, too).
Therefore we'd need a change in the codegen of the CALL and of the internal RETURN of the callee...

I'll have a look at how much work this is and either add it or otherwise raise a PENDING for PROGRAM RETURNING (and in each case make sure that --debug doesn't raise a SIGSEGV but a clear message).