RE: [Tiny-cobol-users] Re: Another observation about subroutines.

[Glen C. <gco...@US...>]

> This is somewhat dangerous, as the C program don't really know the size of
> the variable and could do anything, even write nulls to the end of the
> variable (this belongs to another variable, of course).

That's one of the 'endearing' features of Cobol - subroutines can corrupt
the storage of calling programs.  Possibly there should some boundary
checking, but I'm afraid that if we make changes to the calling conventions,
precompilers and external libraries might no longer work (Oracle for
example).

> Please think a little more about this.  As we are doing it from (almost)
> the ground up, we can choose anything we find useful.  Let also see what
> the others have to tell us about this...
> (^G^G^G^G^G^G  are you hearing me????? ^G^G^G^G^G^G^G^G^G)
> I suggest also we look at other software manufacturers (besides the bug
> blue) about their methods for doing subprograms and extensions in C or
> other non-cobol languages.  Any docs are welcome.

MicroFocus uses a compiler argument to specify the calling convention
(Pascal, C).  We could have it both ways if we had enough programmers to
write multiple calling convention code :)

> Well, the symbol table don't exists anymore at the runtime.  The only
> information we have about the symbols are what is declared at "struct
> fld_desc", much less than "struct sym".  Functions in "C" use the stack to
> store the "bp" register (base pointer) to request automatic variables, so
> it's diffiult to know what's deeper in the stack (that's why we have
> var_args functions to access variable number of arguments).

We will need to find a way to pass some form of symbol table to the runtime
for a debugger.

> > Some I*B mainframe COBOL compilers for example have a special variable
> > called RETURN-CODE, which are set by the programmer, and are
> > equivalent to the C statement return int.

Also RETURN-CODE in AcuCobol, MicroFocus and other compilers I have used.

> What I don't understand is why you are concerned with calling C functions
> now. Please, let us finish the missing statements and we turn to make the
> mathematical functions and other C functions.

Oracle has released a version for Linux.  If our calling conventions are
compatible with Oracle, people will be able to write Cobol programs using
Tiny-Cobol to access Oracle.  I think that this would add significant
functionality and usability from very early releases.  This might be very
desirable (see the oracle sample code in the test_suite/compile_tests
directory.)