@Mário, not related to performance or security issues, I just concern about encapsulation, for better code organization and more readable code, so for that case, I think I should use subprogram instead. Thanks for your elaborate answers!
Thanks, Mário. That way works fine, but the only problem is that foo1 will be exposed to the global environment, instead of local to foo.
Hi Mário, Firstly I try to use FUNCTION nested in PROGRAM, but it seems that FUNCTION is not allowed to be nested in PROGRAM, then I go to try using subprogram instead, and encountered that problem.
OK, see https://sourceforge.net/p/open-cobol/bugs/509/
SIGSEGV when CALL program with RETURNING
Thanks, Pat. After I changed PICTURE 9 to USAGE BINARY-LONG, same error. BTW, is only BINARY-LONG can be used in RETURNING a GnuCOBOL specific restriction, or COBOL in general?
Hi all, Not sure if I do something wrong, but I just can not make it work to CALL program with RETURNING, e.g.: foo.cob: PROGRAM-ID. foo. DATA DIVISION. WORKING-STORAGE SECTION. 01 n PICTURE 9. PROCEDURE DIVISION. CALL 'foo1' RETURNING n END-CALL DISPLAY n END-DISPLAY. END PROGRAM foo. foo1.cob: PROGRAM-ID. foo1. DATA DIVISION. LINKAGE SECTION. 01 n PICTURE 9 VALUE ZERO. PROCEDURE DIVISION RETURNING n. END PROGRAM foo1. Output: % cobc -F -W -j -x foo.cob foo1.cob attempt to reference unallocated...
In 11.8.3, all UNSIGNED are enclosed in square brackets, which I think means optional, so BINARY-CHAR [ UNSIGNED ] means that BINARY-CHAR and BINARY-CHAR UNSIGNED are equal, which is not true, as BINARY-CHAR defaults to SIGNED instead of UNSIGNED. So that following: COBOL C BINARY-CHAR [ UNSIGNED ] unsigned char BINARY-CHAR SIGNED signed char ... should be changed to: COBOL C BINARY-CHAR [ SIGNED ] signed char BINARY-CHAR UNSIGNED unsigned char ...