Explicit and Implicit Definitions of Pointers in Call Prototypes

Restriction: This topic applies to UNIX environments only.

The demonstration program demo3.cbl shows how prototypes are used to create implicit definitions of pointers within scanned programs, and how incompatible parameters are reported.

  1. Create the intermediate code file: Windows:
    cobol demo3.cbl /anim /nognt;
    UNIX:
    cob -a demo3.cbl
    The parameter to which you should pay attention in this program is the ptrnum-g group item. Without prototypes for the various calls used within this program this source file pass through Scan64 without problems.
  2. Run Scan64 on this program by entering the command: Windows:
    cblscan64 demo3
    UNIX:
    cobscan64 demo3
    This produces the following report:
    Processing file 'demo3.int' 
    Finished file 'demo3.int' - pointer usage is OK
  3. However, if you specify a prototype, the program no longer passes through Scan64 without problems. For example, specifying: Windows:
    cblscan64 -m -t demoproto.cpy demo3
    UNIX:
    cobscan64 -m -t demoproto.cpy demo3
    gives:
    Processing file 'demo3.int' 
    **Possible unsafe modification of 'BY REFERENCE' pointer parameter 
    **in CALL 'CBL_ALLOC_MEM' statement at (file: demo3.cbl, line: 10) 
      Modifier : PTRNUM-G (file: demo3.cbl, def: 5) 
      Pointer : MEM-PTR a formal parm 
                (file: demoproto.cpy, def: 17, ref: 29, no: 1) 
              in CALL prototype of CBL_FREE_MEM 
                (file: demoproto.cpy, def:28) 
              as implicitly def'd by CALL at (file: demo3.cbl, line: 10) 
    
    **Possible unsafe modification of 'BY VALUE' pointer parameter 
    **in CALL 'CBL_FREE_MEM' statement at (file: demo3.cbl, line: 13) 
      Modifier : PTRNUM-G (file: demo3.cbl, def: 5)
      Pointer : MEM-PTR a formal parm 
                (file: demoproto.cpy, def: 17, ref: 29, no: 1)
              in CALL prototype of CBL_FREE_MEM 
                (file: demoproto.cpy, def:28) 
              as implicitly def'd by CALL at (file: demo3.cbl, line: 13)
    
    **Unsafe modification of pointer at (file: demo3.cbl, line: 17)
      Modifier : PTRNUM (file: demo3.cbl, def: 6) 
      Pointer : MEM-DUMMY-PTR
                (file: demoproto.cpy, def: 19) 
              of formal parm MEM-DUMMY-PTR-G
                (file: demoproto.cpy, def: 18, ref: 32, no: 1)
              in CALL prototype of CBL_DUMMY_ALLOC_MEM 
                (file: demoproto.cpy, def:31)
              as implicitly def'd by CALL at (file: demo3.cbl, line: 15) 
    
    Finished file 'demo3.int' - pointer problems could exist 
    This report contains two kinds of warning:
    • At lines 10 and 13, the calls to CBL_ALLOC_MEM and CBL_FREE_MEM expect a pointer directly; instead they receive a group item containing a data item defined as pic x(4). This redefines the formal parameter pointer MEM-PTR as an alphanumeric data item, and is a source code problem. If pointers are expected by an API, then pointers must be provided.
    • At line 17, while the problem is more complicated, the reason is roughly the same as that given above. The reported problem stems from the call to CBL_DUMMY_ALLOC_MEM at line 15; this routine expects a group item containing a pointer. The calling program, however, passes a group item containing a data item defined as pic x(4). Because of the complex nature of group definitions and the redefinitions within them, this is not reported directly; Scan64 instead creates an implicit pointer definition at the data location in the program at which the call prototype expected a pointer to be defined. Any operations on the memory occupied by this implicitly defined pointer that are not consistent with pointer usage are then flagged as needing attention. The statement at line 17 is, then, an invalid modification of the memory location occupied by the implicitly defined pointer.