Re: win32ada design question/problem

[dennison@telepath.com]

In article <36519A6A.C07508F5@elca-matrix.ch>,
  Mats.Weber@elca-matrix.ch wrote:
> dennison@telepath.com wrote:
> >
> > In article <ubtm7cxj0.fsf@gsfc.nasa.gov>,
> >   Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote:
> > >
> > > While I agree it wasn't well designed, I don't agree you need to go to
> > > a thick binding. The binding should use 'out' parameter modes in the
> > > places where C uses pointers to achieve output parameters. Most
> > > compilers will map an 'out' parameter to a C pointer, since that's
> > > what 'by reference' means.
> >
> > Actually, according to B.3(68), that is *required* behavour. The problem
with
> > that technique is that many C routines attach a signifigance to a incomming
> > value of null. You won't be able to produce such a value on the Ada side, so
> > some of the functionality of the C routine will be lost.
>
> And there is another, more severe problem. The C function may allocate
> some memory that you must free later, e.g.
>
> procedure P (X : out Some_Record_Type);
> pragma Import(C, P);
>
> now as you have no pointer to the returned data, you cannot free it.
>
> I think the Ada 83 classic int + System.Address approach is better in
> this case.
>

I'm trying to write some portable bindings to the Zlib compression library
right now, and have found myself reverting to just that. But are there
portability issues associated with System.Address? My reading of 13.7 is that
System.Address does not nessecarily map to a C pointer, and that
System.Null_Address does not nessecarily map to a C null pointer.

The "portable" alternative we are given is Interfaces.C.Pointers. But its a
real pain to use for routines where the input object could be any type.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own