Re: [open-cobol-list] PASSTHROUGH experiment

[Brian Tiffin]

On Thu, 07 Feb 2013 10:56:11 -0500, Patrick  
<address@hidden> wrote:

> Hi Everyone
>
> So for 8 years I have been teaching myself to program in the evenings
> after the kids go to bed(I service spectrometers in the day) and for 8
> years I have been littering the internet with stupid questions. I have
> failed and failed and failed but I have also learned quite a bit in the
> process.
>
> So I have been looking at the OC source code and I am very excited. All
> the C books I have read seem to make sense now and all the compiler
> books seem to be making sense now too.
>
> It will take me another month of evenings to understand the source code
> but I can see it is built from standard components like Autotools, Flex
> and Bison, there is lot of documentation to help outside of the OC  
> project.
>
> I was investigating gobject introspection in order to write a GTK
> binding but now I have another idea. What about modifying open Cobol
> itself to pass through certain variables directly to C skipping the
> normal checks an stuff.
>
> So lets say that there is a C library that has the function POO and I
> want to pass the value 2 and a user defined C type FOO. Right now there
> is no way to represent FOO in OC or it is difficult.
>
> What about something like this:
>
> 05 FOO PIC PASSTHROUGH .
>
> or if the C library uses some crazy name, a way to rename it on the
> Cobol side but emitted correctly on the C side
>
> 05 crazy PIC PASSTHROUGH VALUE SomeCrazyNameInC.
>
>
> Aside from modifying Cobol outside of the standard does anyone see any
> issues with this approach?

Hello, Patrick;

Yeah there would be some issues with this, and there are some pretty  
simple existent workarounds using thin wrappers.

I've found that most of the C ABI is available from pure OpenCOBOL, and  
the edge cases only require a thin layer of C to fill in all other  
features and functionalities.

Usually defining struct equivalents in COBOL groups is as easy as adding  
SYNCHRONIZED to the working-storage definitions.   
http://www.opencobol.org/modules/newbb/viewtopic.php?topic_id=1110&forum=1#forumpost5484

One area that gets dicey is registering callbacks that don't have C int  
return types.  Another is void returns (though a fix is available, but not  
integrated into OpenCOBOL-1.1 Community Edition just yet).

One of the nice features of OpenCOBOL is that cobc knows what to do with  
.c files.

$ cobc -x program.cob utilities.c

will compile program and properly link to any symbols or functions in  
utilities.c

Now, having said all the above, I don't want to discourage ANY experiments  
with OpenCOBOL, as experiments lead to discoveries.  One thing we do want  
to avoid with OpenCOBOL is getting too far away from official or defacto  
standard COBOL.  (Having said that, I'd like to see open COBOL have some  
influence on the next official COBOL draft, which will likely be COBOL  
2020 (or later)).

I used to be where you are now, I think, wondering how integration with C  
could be optimized, but it turns out that it's pretty close as it is.  I  
now look to pure OpenCOBOL first, and only fallback to C wrappings when  
the callframes can't be properly formed (or wonky C preprocessor macros  
are required, or as in your example, if extern names are in conflict with  
COBOL rules).  Turns out that that is more rare than you might think  
(especially with SYNC support).

And sometimes, C code just seems the proper place to put some  
functionality (but I lean toward leveraging Vala code for those times now,  
and have Vala/Genie generate .c files that cobc can pick up and use).

On GObject;  I had a small conversation with the Vala team, and I kinda  
volunteered to try adding GObject Introspection to cob_field.  If that  
works, then OpenCOBOL would have seamless handling of C header information  
within GLib space and GObject projects would have nearly seamless  
integration to OpenCOBOL libraries.  That would be cool.

Cheers,
Brian