If an element is marked GLOBAL in the LINKAGE SECTION and is used in a subroutine, the generated C code references a non-existent variable and is therefore not compilable.
Minimal example:
IDENTIFICATION DIVISION.
PROGRAM-ID. PARENT.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 SOON-TO-BE-GLOBAL.
05 FILLER PIC X(15) VALUE "Test value".
PROCEDURE DIVISION.
CALL "CHILD" USING SOON-TO-BE-GLOBAL
GOBACK.
END PROGRAM PARENT.
******************************************************************
******************************************************************
IDENTIFICATION DIVISION.
PROGRAM-ID. CHILD.
DATA DIVISION.
LINKAGE SECTION.
01 GLOBAL-ELEMENT GLOBAL.
05 FILLER PIC X(15).
PROCEDURE DIVISION USING GLOBAL-ELEMENT.
CALL "NESTED"
GOBACK.
******************************************************************
IDENTIFICATION DIVISION.
PROGRAM-ID. NESTED.
PROCEDURE DIVISION.
DISPLAY GLOBAL-ELEMENT *> C code references invalid variable
GOBACK.
END PROGRAM NESTED.
END PROGRAM CHILD.
I thought it has to be GLOBAL in all program / modules that use it.
However when changed all see lower I got :
[vince@applewood tmp]$ cobc -x test1.cbl
[vince@applewood tmp]$ ./test1
attempt to reference invalid memory address (signal)
Last statement of "NESTED" unknown
Last statement of "CHILD" unknown
Last statement of "PARENT" unknown
Started by ./test1
Segmentation fault (core dumped)
Code :
Compiler :
cobc -V
cobc (GnuCOBOL) 3.2-rc1.0
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built Jan 18 2023 18:33:19
Packaged Jan 18 2023 18:31:41 UTC
C version "10.4.0"
Same result when moving the END PROGRAM PARENT. to the end of source
That is also interesting. So two bugs? We have verified that my originally posted source code compiles and works as expected on IBM COBOL. For the sake of minimal example, we merged the parent and child programs in one source, but originally we encountered the bug when they were separate.
I think I found another bug, but related to this one. Again, a variable is used in the C code which does not exist in its scope.
I should probably mention I'm using GnuCobol 3.1.2:
Those issues will be investigated before 3.2 final, likely sometime around February 21.