Re: GnuCOBOL call parameter problem.

[Ron Norman]

That might be a "new feature" but at present I am just working on getting the simple case to work as they expect without breaking anything else.

On Sat, Jun 6, 2020 at 3:18 PM Simon Sobisch <simonsobisch@web.de> wrote:

The module could pass the parameters and the cob_fields from LINKAGE to
a function in libcob/call.c if the caller is not COBOL.
This function will then check the parameters, set the number of
parameters handling void as OMITTED and possibly setup stuff like the
parameter length for ANY LENGTH.

Simon

Am 06.06.2020 um 21:05 schrieb Ron Norman:
> I almost have this test case working both with and without cobcall.
> It will only work without using cobcall if the COBOL subroutine has
> nothing like ANY LENGTH or ANY NUMERIC.
>
> On Sat, Jun 6, 2020 at 2:37 PM James K. Lowden <jklowden@schemamania.org
> <mailto:jklowden@schemamania.org>> wrote:
>
>     On Fri, 5 Jun 2020 19:49:50 -0400
>     Ron Norman <rjn@inglenet.com <mailto:rjn@inglenet.com>> wrote:
>
>     > Being compatible with Microfocus is an important feature of GnuCOBOL.
>
>     Agreed. 
>
>     > Just getting the C API working a few years ago was a far bit of
>     > effort
>
>     No doubt, and I'm glad for it. 
>
>     My point, simply, is that there's no technical *need* for cobcall
>     (although it could be used by programs that expect it).  libcob is
>     written in C, and its functions are C functions.  I'm hoping you will
>     explain what dependencies exist in libcob on cobcall, so that they
>     can be removed, thereby making cobcall strictly optional. 
>
>     That would not only make mixing C and Cobol easier; it should simplify
>     code generation and interaction between the compiled module and the
>     runtime library. 
>
>     --jkl
>
>
>
>
> --
> Cheers
> Ron Norman

--

Cheers

Ron Norman