From: Al Johnston <sofeise@mindspring.com>
Subject: Re: New to ada95: porting
Date: 2000/02/29
Date: 2000-02-29T06:58:06+00:00 [thread overview]
Message-ID: <38BB6D88.84BBF5BF@mindspring.com> (raw)
In-Reply-To: _VGu4.1139$NO6.104993@bgtnsc06-news.ops.worldnet.att.net
> Look at the standard C interface utilities in the packages
Thanks, I have... I just don't know what to do with them..
for example:
1) cohen's book give an example of an interface to getenv() using
IF.C.Strings, but the gnat adainc code doesn't both with this
level, favoring a 'address of an unconstrained array.
2) how in the world do you implement a c char** as a
parameter in a procedure call?
3) I have a lot of these types of things in my current (8x) ada
code:
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.
Obviously, this is very nasty... and I have no expectation
that it will work under gnat (this stuff was written long ago
for sunAda; sun published there "dope vector" format and
my predecessor took advantage of it... and now I get to
pay).
Anyway, the above is the class of thing I am having trouble
figuring out how to re-code. I desperately need an example
of the right way of doing this. I was thinking about using
IF.C.Pointers on this one... but the outer private "element"
has a component that would need to be a inner private
"element" and at that point I get lost.
Well, those are the major types of issues that I am
confused on...
tnx for any guidance... at the moment recoding everything
in c is looking attractive. We have a hell of a lot of these
types of structures (they are related to RPC client code).
-al
>
> When in doubt read the Reference Manual.
I don't have a problem reading the RM.... understanding it, however, is
another story :{
-al
next prev parent reply other threads:[~2000-02-29 0:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-28 0:00 New to ada95: porting Al Johnston
2000-02-29 0:00 ` James S. Rogers
2000-02-29 0:00 ` Al Johnston [this message]
2000-02-29 0:00 ` tmoran
2000-02-29 0:00 ` Al Johnston
2000-02-29 0:00 ` james hopper
2000-03-01 0:00 ` Al Johnston
2000-03-01 0:00 ` tmoran
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox