Re: GnuCOBOL call parameter problem.

[Ron Norman]

Completely disagree. 

Your suggestions are not something I would accept. 

There is an extensive API for C to get/put COBOL data. 

GnuCOBOL emits C as an intermediate step to get executable code. 

Peeking inside the C code that is generated is something C programmers should 
avoid. 

COBOL programmers should not dig too deep into what GnuCOBOL emits. 
The intent is that the C code emitted is never kept.  
Only the GnuCOBOL developers should really be concerned about it. 

Cheers,
Ron Norman
(Sent from my iPhone)

> On Jun 6, 2020, at 19:34, James K. Lowden <jklowden@schemamania.org> wrote:
> 
> On Sat, 6 Jun 2020 15:00:00 -0400
> Ron Norman <rjn@inglenet.com> wrote:
> 
> I *do* appreciate your attention to this, Ron.  I haven't looked at
> r3587, but I recognize the priority you gave it.  Thank you.  
> 
> What I want to forge is an agreement in principle about how C and Cobol
> should interact. I'm not sure were there yet.  
> 
>> Parameters can be optional and the variable NUMBER-OF-CALL-PARAMETERS
>> needs to be set correctly.
> 
> Variadic functions have been part of standard C since 1999.  
> 
> NUMBER-OF-CALL-PARAMETERS should be eliminated from libcob.  Any
> function with an optional number of parameters should be defined as per
> stdarg (3).   
> 
> Unused optional arguments are conventionally passed as a compile-time
> constant, recognized by the called function.  One popular choice is a
> NULL pointer.  
> 
> If you want to use NUMBER-OF-CALL-PARAMETERS from Cobol, and a helper
> function like cobcall because you think that helps, or because that's
> the MF way, that's fine.  Put it in the compiler.  Let's not let
> concerns like that define the libcob API.  
> 
>> Also some parameters can be defined as ANY LENGTH or ANY NUMERIC and
>> for those to work the caller should be COBOL.
> 
> Define a C type to represent an array of ANY LENGTH, and another for
> ANY NUMERIC, probably a discriminated union.  Pass the pointer.
> Next?  
> 
> --jkl
>