#518 Support for MF cbltypes.cpy and cblproto.cpy

[Xavier Del Campo Romero]

MF define two copybooks, namely cbltypes.cpy and cblproto.cpy. These can be COPYed by library users to find the data types used by their libraries and their prototypes, respectively. They also define a few examples (#1, #2) of the copybooks in action.

As a suggestion, cbltypes.cpy could be made available by GnuCOBOL in order to maintain API compatibility with existing applications relying on MF's extensions. Types such as CBL_CHECK_FILE_EXIST rely on data types predefined by the implementation (presumably by cbltypes.cpy), such as cblt-fileexist-buf.

So far, I do not see GnuCOBOL defining any of this. Instead, GnuCOBOL's test suite just allocates a 16-byte buffer, presumably because the size of cblt-fileexist-buf is also 16 bytes, and writes each byte individually.

OTOH while I am aware GnuCOBOL does not support prototypes as of the time of this writing (similarly to GCC-COBOL), an empty stub of cblproto.cpy could at least maintain API compatibility with existing applications as long as prototypes are not supported. Once supported, it then be filled accordingly. Also, IBM recommends the use of function prototypes for several reasons.

Best regards,
Xavi (Symas Corporation)

[Simon Sobisch]

GnuCOBOL fully supports prototypes as far as I know and also internally creates them when compiling. What we don't have yet ("just needs a patch") is someone that writes the prototype information to a specified file and reads it from there as well.

Those are heavily used for example in COBJAPI since years.

Moving our existing internal checks for runtime library calls (system.def) in cobc to function prototypes would already be possible and very useful, as we currently only do a partial check on those (like amount of arguments).

The same cannot be done with the intrinsic functions as prototypes work with fixed amount of arguments without reserved words, but we could possibly extend that.

Concerning the types - they came after the initial implementation also in MF/ACU/... their old documentation original - using system library calls without them is most reasonable :-)

... but yes, I'd like to include them in our distribution. They can then also be copied to GCC-COBOL.

For the two files mentioned (note - there are also related C header files for those) I'm already in contact with the FSF,.

[Xavier Del Campo Romero]

I have prepared the following minimal reproducible example in a tarball that fails to build on GnuCOBOL r5627:

$ make
cobc -c -o foo.o foo.cbl
foo.cpy:2: warning: handling of FUNCTION PROTOTYPE is unfinished; implementation is likely to be changed [-Wunfinished]
    1 |        identification division.
    2 >        function-id. foo is prototype.
    3 |        data division.
    4 |        linkage section.
cobc -c -o main.o main.cbl
foo.cpy:2: warning: handling of FUNCTION PROTOTYPE is unfinished; implementation is likely to be changed [-Wunfinished]
    1 |        identification division.
    2 >        function-id. foo is prototype.
    3 |        data division.
    4 |        linkage section.
main.cbl:10: error: FUNCTION 'foo' unknown
    8 |         77 retcode pic 9.
    9 |        procedure division.
   10 >         move function foo(a, b) to retcode.
   11 |         display "retcode is :" retcode.
   12 |         end program proto.
make: *** [Makefile:20: main.o] Error 1

On this example, a program called proto attempts to call a function, namely foo, whose prototype is COPYed from foo.cpy. To my knowledge, the code example should be fully ISO COBOL 2023-compliant i.e., no MF extensions. However, as shown above main.cbl fails to find the foo function, despite its declaration being right above it.

GnuCOBOL fully supports prototypes as far as I know and also internally creates them when compiling.

The warning and error messages above and seem to indicate otherwise. Is there anything I am missing?

What we don't have yet ("just needs a patch") is someone that writes the prototype information to a specified file and reads it from there as well.

Does this mean the example above is expected to fail because of missing bits and pieces in the implementation?

[Simon Sobisch]

... we don't support MF prototypes - patches welcomed for those, the non-standard extension for the standard feature itself is tracked under [feature-requests:#509]