GPC module restrictions etc_(re)

Fri, 7 Feb 1997 16:07:36 +0100 (MET)

According to Jakob Heinemann:
> I'm looking at GPC to decide wether or not to use it to port a quit
> large application from VMS to Unix.
>
> [...]
>
> According to the
> documentation the GPI-mechanism is not as stable as it should be.
> but what is the actual problem?
> what are the limitations?
> the problem of unsized strings and GPI import? (I get a warning that
> there are incompatible pointers
> when calling an imported function with a varying string.)
> is there som work beeing done to fix it?

Some constructs do not survive transport through a GPI file.
The most important thing is probably the generic String Schema type
(without specified length). This will be fixed next.
There are also some problems concerning file and object types.

As a workaround, you can (*$include *) the Interface Modules into
your source (above the `Program' headline).  Then you can compile the
Implementation Modules separately and link everything together.  This
mechanism is considered stable.

The GPI problem is annoying, but it is solved in theory.  What remains
is a bulk of work to determine which parts of which structure must be
stored in the GPI file.

> Other questions that I also came up with are:
> Calling  functions in C, is easy, just put a C; as a declaration af the
> body. How about
> calling functions in ADA (i.e. Gnat)?

You can import any function written in any language by writing a Pascal
Procedure/Function head for it.  (This does survive transport through
a GPI file.)

The `C' keyword is named in a little misleading way.  It means: "Import
that function and assume that its name is in lowercase." - independent
of the question what compiler produced that function.  For mixed case
you can use the `AsmName' directive:

    Type
      Pointer = ^Void;

    Function XEventsQueued ( Display: Pointer; Mode: Integer ): Integer;
    AsmName 'XEventsQueued';

> The other way around, other
> languages calling
> functions written in Pascal?

No problem if the other language supports that.  For example, to use a

    Procedure FooBar ( x: Integer; Var y: Char );

from a C program, import it as

    extern void Foobar ( int x, char *y );

Note that the First Letter Of The Pascal Name Is Capitalized and does not
depend on how you write the name in your Pascal source.  (The same holds
when debugging a program written in GNU Pascal:  You have to specify all
symbols with one capital letter.)

> The code uses lots of  varying length strings written partly as schemas,
> and partly as some
> sort of conformant arrays in parameter lists. A piece fo code may look
> like this:
> 
> Var    text_str  : varying (. len .) of char ;
> 
> procedure testproc ( str :  varying (.len .) of char );
> var i : integer ;
> begin
>   for i :=3D 1 to len do
>     something(i,str);
> end ;
> 
> This should translate to
> 
> Var text_str : string;
> 
> procedure testproc ( str :  string );
> var i : integer ;
> begin
>   for i :=3D 1 to length(str) do
>     something(i,str);
> end ;

Yes, this should work.  The problem to transport a `String' through a
GPI file is worked on, but for the moment you can include the Interfaces
as a workaround (see above).

> But how about the vax statement for issuing variable amount of
> arguments?
> Vax-pascal:
> 
> procedure test_pro ( var arg1 : integer; [list] therest : integer) ;
> var cnt : integer ;
> begin
>   arg1:=3D 0 ;
>   for cnt :=3D 1 to argument_list_length (therest) do
>     arg1 :=3D arg1 + argument(therest, cnt):
> end;
> 
> Is there a construct for this in GPC? (in that case I=B4m sorry but I
> haven=B4t found it in the manual)

GNU Pascal has an ellipsis parameter for variable argument lists:

    Procedure Test_Pro ( Var arg1: Integer; ... );

but at the moment we do not provide a way to access those arguments.
(However this feature is useful to work with C functions having variable
argument lists.)

Since VAX Pascal seems to provide such a mechanism it could be a good
idea to implement that scheme into GPC, too, instead of inventing a new
method to achive this functionality.  It would be nice if you could tell
me more about this - and perhaps about other nice features of VAX Pascal
which you would like to see in GNU Pascal.  It might be that they are
relatively easy to implement - in that case we would probably do it,
and you can save a lot of work porting your application.

If all additional parameters have the same type, you can use either
conformant arrays or "open arrays" (according to Borland Pascal) to
pass them:

    Procedure Test ( Var arg1: Integer; Var therest: array of Integer );

Then you can pass any array of Integers as the actual parameter; in the
function body the lower bound of the array is assumed to be zero.

> I don=B4t think I'm on the subscriberlist so please post your reply
> directly to me aswell.

I am doing so, so you should get this mail twice if you are on the list.

> (I've tried to subscribe , but I'havent hear anything...)

The list is maintained manually, so delays are possible.  If the delay
lasts too long, please complain to gpc-request@hut.fi.

Even if you are not on the list, you can read it via the list archives
on ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/misc/, updated
daily.  You can also get them through the GNU Pascal WWW home page,
http://home.pages.de/~GNU-Pascal/.

> Thank you guys, Gnu Pascal's  great, but I still miss some important
> consepts from the
> extended pascal definition. (Schemas and module integrity...)
> Hope that all the stuff will be there some day, right now I feel it is
> not so safe
> that it will suit our need for this project, but perhaps in the future..

I am myself porting a large project (104 modules, 102k lines :-P) from
Borland Pascal (DOS) to GNU Pascal (DOS, OS/2, UNIX, ...), so there is
hope that GNU Pascal will become more reliable not too far in the future.
Please be patient - or offer your help!

Thanks for your interest,

    Peter

  Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
       maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)