|
From: | Ron Norman |
Subject: | Re: GnuCOBOL call parameter problem. |
Date: | Sat, 6 Jun 2020 15:54:14 -0400 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |