Re: [Cobolforgcc-devel] CD 1.10 Available - questions?

[Tim J. <te...@me...>]

Bill,

I have some questions are the CD1.10 document which you emailed
the cobolforgcc groups a while back. I know you are busy so I
will try and be as concise and clear as possible.

1. There appears to be no way to have functions that have a
variable number of arguments. You can have optional arguments,
but whereas, in C, functions like printf can have an unlimited
number of arguments, it appears that this is not possible in
CD1.10. Was this a deliberate omission? Obviously it makes it
difficult to interface into existing C libraries.

2. In S4.151, the definition of program prototype seems to be
wrong, cloned from the previous definition. 

3. There is a pointer to a program (8.4.2.11.3) but not to a
function. Is this deliberate? It again makes it difficult to
interface to C libraries, where for example when calling qsort
you have to pass a function pointer.

4. In C.23, 'bit they can' should be 'but they can'.

5. There seems to be a duplication of specification in that in
the prototype you say 'X as "y"' and you say that also in the
repository paragraph. It seems the 'as "y"' name is the real name
and the X name is just a local name which is not externalized. Is
that correct? For example, if the prototype said 'X as "y"' and I
had 'A as "Y"' are they referring to the same function?

----

I would like to write as much of my COBOL compiler in COBOl as
possible, so I am first working on a subset of the language. This
will require access to the C library for many functions, such as
IO. I would like to use the COBOL 2002 standard where it helps in
the regard, particularly functions, binary data items and
prototypes. Maybe also BIT types and boolean operations. 

The main issue is the function prototypes. I don't really have a
very clear idea of the role of the repository, and to me it seems
to make life a little more complex, so I want to avoid it if
possible for now. 

So what I was intending to do was have each program do as
follows:

** get prototypes of all functions used...

COPY FPRINTF.

* FPRINTF will be some code containing the prototype for fprintf
as follows:

*** start copy 

ID division.
FUNCTION-ID. FPRINTF as "fprintf" is prototype.

...etc

end-function fprintf.

*** end copy

ID DIVISION.
PROGRAM-ID. X1.

...

REPOSITORY.

FUNCTION FPRINTF as "fprintf".

...

Procedure division.

   result=FPRINTF(a,b,c).

...

end-program x1.

-----------------

As far as I can tell, this will be legal COBOL 2002. Does this
approach seem sensible to you, or should I adopt a different
approach.

What is the role of the repository? As far as I can tell it works
like this:

1. You do compiles and tell the compiler to place the prototypes
for functions classes and interfaces into the repository. This is
how the repository get populated.

2. You compile other programs and reference the programs in the
repository via the repository paragraph. This is how the
repository gets used. 

The reason for the repository would seem to be, to allow the
prototype information to be stored in very efficient form. As
everyone knows, in C++ most compilation times are dominated by
the processing of the headers. Is my supposition correct? Or is
there another reason? 

Regards,
Tim Josling