Re: New to ada95: porting

[tmoran@bix.com]

>type NSV is array(positive range <>) of ordinal
>type NSVP is access NSV;
>type NI is record
>    id : positive
>    h : NSVP;
>end record;
>type HSV is array(positive range <>) of NI
>type HSVP is access HSV;
>
>This is used in an ada routine that calls a c routine.  currently
>the c routine allocates the memory (including two different
>types of dope vectors) and loads the structure and returns
>it as a pointer, so when the ada code receives its value
>for the inout arg of HSVP it thinks the unconstrained
>array parts are "normal" ada unconstrained arrays.
  So you have something like
    function In_C return  HSVP;
    pragma import(C, In_C, "InC");
and after calling it you can run the code:
and you can run the code
  P : HSVP := In_C;
begin
  for i in P.all'range loop
    Ada.Text_IO.Put_Line("id" & integer'image(P.all(i).id));
    for j in P.all(i).h.all'range loop
      Ada.Text_IO.Put_Line(ordinal'image(P.all(i).h.all(j)));
    end loop;
  end loop;
and it works?
  If the dope vector stuff as built by your C code does not match
what your (new) Ada compiler wants, you'll have to either change
the C to make something that does match, or else change the Ada
spec to match what the C code generates.  Have you decided on
the latter?  In which case the problem seems to be "how do I
specify in Ada 95 a data structure that matches the thing
returned by In_C", possibly ignoring some dope vector info while,
for instance, using other parts as discriminants to specify
array sizes.
  Or do you instead wish to leave the old Ada specs alone, but
change the C code to build the data structures those specs
now lead to?
  What did the old (publicly specified) dope vectors look like?
Do you have a lot of similar structures, or is the HSVP one
a worst case?