Ada equivalent for C-pointer?

Ada equivalent for C-pointer?

[Alfred Hilscher]

I want to interface to a C-function expecting a "far *", what have I to
pass: an "access all ..." or "System.Address"? Are there differences
between access and address, or are their internal representations equal?
I use GNAT 3.15p.

 
-----------------------------------------------------
To send me mail, please replace "Spam" by "Jedermann"
-----------------------------------------------------

Re: Ada equivalent for C-pointer?

[Duncan Sands]

Hi Alfred,

> I want to interface to a C-function expecting a "far *", what have I to
> pass: an "access all ..." or "System.Address"? Are there differences
> between access and address, or are their internal representations equal?
> I use GNAT 3.15p.

a System.Address is what you would expect a pointer to be: a (eg) 32 bit
number referring to a memory address, like a C pointer.  Most access types
will be the same size as, and equivalent to, a System.Address, but some
access types may be bigger ("fat pointers") because they contain some
information about what they are pointing to.  This is typical of access
to unconstrained array types for example, where the access type usually
holds a memory address and also the array bounds.  What you should do is
create an access type with convention C:

	type C_Pointer is access ...
	pragma Convention (C, C_Pointer);

Here ... is whatever it is your pointer is pointing to, or anything (eg: Integer)
if you are not actually going to dereference the pointer in your Ada program.  The
pragma makes sure that the access type is what a C program expects, basically a
System.Address.

Ciao,

Duncan.

Re: Ada equivalent for C-pointer?

[tmoran]

>a System.Address is what you would expect a pointer to be: a (eg) 32 bit
>number referring to a memory address, like a C pointer.
  Wrong.
>Most access types
>will be the same size as, and equivalent to, a System.Address, but some
  Wrong.
There is no requirement that a System.Address have any particular
representation.  For instance, quoting from the manual for a compiler
that handles the general segment:offset form of addressing in
Intel 8086 descended chips:
  type Address is record
    Offset : Offset_Type;
    Segment: Word;
  end record;
which is 48 bits.

>some access types may be bigger ("fat pointers") because ...
 Right.  Two different access types may have two different
representations, and neither is necessarily the same as a C pointer.

>       pragma Convention (C, C_Pointer);
  Right.  In Ada, one asks the compiler to handle such low-level stuff,
rather than worrying about it or trying to sneakily do it yourself.
That's why there is a pragma Convention to tell the compiler you want
something to be compatible with C (or Fortran, or whatever).

  Separately, and probably irrelevantly for the OP, there is a
package System.Address_to_Access_Conversions to let you tell the
compiler to convert between whatever form it is using for a particular
access type, and whatever form it is using for a System.Address.

Re: Ada equivalent for C-pointer?

[Brian May]

>>>>> "Alfred" == Alfred Hilscher <SPAM@alfred-hilscher.de> writes:

    Alfred> I want to interface to a C-function expecting a "far *",
    Alfred> what have I to pass: an "access all ..." or
    Alfred> "System.Address"? Are there differences between access and
    Alfred> address, or are their internal representations equal?  I
    Alfred> use GNAT 3.15p.

>>>>> "tmoran" == tmoran  <tmoran@acm.org> writes:

[...]

    tmoran> There is no requirement that a System.Address have any
    tmoran> particular representation.  For instance, quoting from the
    tmoran> manual for a compiler that handles the general
    tmoran> segment:offset form of addressing in

    tmoran> Intel 8086 descended chips:
    tmoran> type Address is record
    tmoran> Offset : Offset_Type;
    tmoran> Segment: Word;
    tmoran> end record;
    tmoran> which is 48 bits.

Hello,

To the best of my knowledge "far" pointers or pointers referring to
segment:offset are obsolete in modern 32 bit Intel code unless you are
writing low level OS code (e.g. device drivers).

This is because the segmented model was considered painful for
programmers to use (especially early Intel versions). As such, the 32
bit Intel processors still uses segments (although the meaning of the
word has changed since 8086), the operating system maps one big
segment to use for all data by a given program, and the application
programmer doesn't have to worry.

I would speculate that the "far" in this case may be ignored and is
just a left over from old 16 bit MSDOS/Windows code.

Unless this code is 16 bit MS-DOS/Windows code or low level operating
system code (the poster didn't specify so I assumed this wasn't the
case).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada equivalent for C-pointer?

[Keith Thompson]

Alfred Hilscher <SPAM@alfred-hilscher.de> writes:
> I want to interface to a C-function expecting a "far *", what have I to
> pass: an "access all ..." or "System.Address"? Are there differences
> between access and address, or are their internal representations equal?
> I use GNAT 3.15p.

"far" pointers are an old Microsoft kludge.  The C standard doesn't
define "far" pointers, and an Ada compiler's interface to C likely
doesn't either.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Re: Ada equivalent for C-pointer?

[Stephen Leake]

Keith Thompson <kst-u@mib.org> writes:

> Alfred Hilscher <SPAM@alfred-hilscher.de> writes:
> > I want to interface to a C-function expecting a "far *", what have I to
> > pass: an "access all ..." or "System.Address"? Are there differences
> > between access and address, or are their internal representations equal?
> > I use GNAT 3.15p.
> 
> "far" pointers are an old Microsoft kludge.  The C standard doesn't
> define "far" pointers, and an Ada compiler's interface to C likely
> doesn't either.

To be somewhat more helpful:

On older x86 systems, when 16 bit operating systems were used, there
were two kinds of pointers; "near" pointers, 16 bits in size, and
"far" pointers, 32 or 48 bits in size.

These days, you should interpret "far" as a noop, and just think of it
as a pointer.

Whether it is 16, 32, or 64 bits depends on what machine, OS, and
compiler you are using.

-- 
-- Stephe

Re: Ada equivalent for C-pointer?

[Nick Roberts]

Stephen Leake <stephen_leake@acm.org> wrote:

> On older x86 systems, when 16 bit operating systems were used, there were
> two kinds of pointers; "near" pointers, 16 bits in size, and "far"
> pointers, 32 or 48 bits in size.
> 
> These days, you should interpret "far" as a noop, and just think of it as
> a pointer.

I want to be pedantic about this; please bear with me.

In what is called the 'flat' 32-bit memory model, a far pointer is the same
as near pointer (a 32-bit absolute offset, on its own). Since 32-bit Windows
(and indeed 32-bit Linux) only uses the flat memory model, this mode
appertains mandatorily.

However, in 32-bit segmented mode, a far pointer comprises a 32-bit offset
plus a 16-bit segment selector. These are stored in memory in a format which
is 64 bits in size (16 bits are wasted).

I understand there are some C compilers which support 32-bit segmented mode
compilation (e.g. WATCOM), but GCC never has and probably never will.

The distinction may seem pointless (sorry :-) to most people, but it matters
to me (because it will matter to AdaOS ;-)

To clarify, when we are talking about near and far pointers, we are
specifically talking about the 32-bit Intel Architecture (IA-32). I'm not
aware of any other contemporary architecture supporting a superimposed
segmentation scheme.

-- 
Nick Roberts

Re: Ada equivalent for C-pointer?

[tmoran]

>However, in 32-bit segmented mode, a far pointer comprises a 32-bit offset
>plus a 16-bit segment selector. These are stored in memory in a format which
>is 64 bits in size (16 bits are wasted).
   Which compilers waste memory like that?

Re: Ada equivalent for C-pointer?

[Keith Thompson]

tmoran@acm.org writes:
>>However, in 32-bit segmented mode, a far pointer comprises a 32-bit offset
>>plus a 16-bit segment selector. These are stored in memory in a format which
>>is 64 bits in size (16 bits are wasted).
>    Which compilers waste memory like that?

I don't know, but presumably it's worth wasting 16 bits per far
pointer to be able to align on a 32-bit boundary.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Re: Ada equivalent for C-pointer?

[Randy Brukardt]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:gemini.iad826000p84p02bc.nick.roberts@acm.org...
...
> In what is called the 'flat' 32-bit memory model, a far pointer is the
same
> as near pointer (a 32-bit absolute offset, on its own). Since 32-bit
Windows
> (and indeed 32-bit Linux) only uses the flat memory model, this mode
> appertains mandatorily.
>
> However, in 32-bit segmented mode, a far pointer comprises a 32-bit offset
> plus a 16-bit segment selector. These are stored in memory in a format
which
> is 64 bits in size (16 bits are wasted).
>
> I understand there are some C compilers which support 32-bit segmented
mode
> compilation (e.g. WATCOM), but GCC never has and probably never will.

Janus/Ada supports that on DOS extenders (although System.Address is a
48-bit type, not 64 -- alignment might cause the other 16-bits be to wasted,
but it is certainly not part of the type). It used to support that on
Windows as well (by default, really), but it caused too much trouble with
use of 'Address. DOS Extenders these days are mostly used in embedded
systems (they're not really DOS extenders, but rather an very small embedded
OS).

For DOS Extenders, Janus/Ada separates the code and data segments, so that
errant programs can't write the code segment or execute the data segment.
That seems like a basic and trivial precaution to me; most of the security
exploits couldn't have happened if Windows and Unix had done that. (Sure,
there are occassional legitimate uses for excuting code written by the
program; but that is an exceptional case, and should be treated that way.)

> The distinction may seem pointless (sorry :-) to most people, but it
matters
> to me (because it will matter to AdaOS ;-)
>
> To clarify, when we are talking about near and far pointers, we are
> specifically talking about the 32-bit Intel Architecture (IA-32). I'm not
> aware of any other contemporary architecture supporting a superimposed
> segmentation scheme.

Right, which is probably why it hasn't been used in other systems. But
virtually every system has a way to mark pages as read-only and no-execute,
and it's silly that that wasn't used to protect programs and system.

                               Randy.

Re: Ada equivalent for C-pointer?

[Martin Krischik]

Alfred Hilscher wrote:

> 
> I want to interface to a C-function expecting a "far *", what have I to
> pass: an "access all ..." or "System.Address"? Are there differences
> between access and address, or are their internal representations equal?
> I use GNAT 3.15p.

Read for infos about access:

http://en.wikibooks.org/wiki/Programming:Ada:Types:access

And for C especialy the chaper:

http://en.wikibooks.org/wiki/Programming:Ada:Types:access#C_compatible_pointer

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada equivalent for C-pointer?

[Nick Roberts]

Alfred Hilscher <SPAM@alfred-hilscher.de> wrote:

> I want to interface to a C-function expecting a "far *", what have I to
> pass: an "access all ..." or "System.Address"? Are there differences
> between access and address, or are their internal representations equal? I
> use GNAT 3.15p.

Assuming you are passing parameters to a C function, it should be very
simple.

For example, if there is a C function defined thus:

   int wibble(int *n);

then in Ada you can declare:

   function Wibble (Number: in out Interfaces.C.int);
   pragma Import(C,Wibble,"wibble");

and it should work. (Obviously, you must link the C functions in somehow.)

If you were to give more information about what you are really trying to
achieve, we can probably give you more accurate and detailed answers.

-- 
Nick Roberts

Re: Ada equivalent for C-pointer?

[Pascal Obry]

Nick Roberts <nick.roberts@acm.org> writes:

> For example, if there is a C function defined thus:
> 
>    int wibble(int *n);
> 
> then in Ada you can declare:
> 
>    function Wibble (Number: in out Interfaces.C.int);
>    pragma Import(C,Wibble,"wibble");
> 
> and it should work. (Obviously, you must link the C functions in somehow.)

I don't think so. Here Number will be passed by value, no? And you also need
the returned value ;)

So, you probably want:

    function Wibble (Number: access Interfaces.C.int) return Interfaces.C.int;
    pragma Import(C,Wibble,"wibble");

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada equivalent for C-pointer?

[Nick Roberts]

Pascal Obry <pascal@obry.net> wrote:

> I don't think so. Here Number will be passed by value, no?

No, I don't think so (with GNAT/GCC).

> And you also need the returned value ;)

Yes, oops!

> So, you probably want:
> 
>     function Wibble (Number: access Interfaces.C.int)
>           return Interfaces.C.int;
> 
>     pragma Import(C,Wibble,"wibble");

I think the 'in out' mode would work with GNAT/GCC, but I'd suggest testing
it to make sure. I suppose using the 'access' mode might be clearer, and it
might be slightly more efficient.

-- 
Nick Roberts

Re: Ada equivalent for C-pointer?

[Simon Wright]

Nick Roberts <nick.roberts@acm.org> writes:

> I think the 'in out' mode would work with GNAT/GCC, but I'd suggest
> testing it to make sure. I suppose using the 'access' mode might be
> clearer, and it might be slightly more efficient.

with Interfaces.C;
function Wibble (Number: in out Interfaces.C.int) return Interfaces.C.int;
pragma Import(C,Wibble,"wibble");

smaug.pushface.org[4]$ gnatgcc wibble.ads
wibble.ads:2:18: functions can only have "in" parameters

-- 
Simon Wright                               100% Ada, no bugs.

Re: Ada equivalent for C-pointer?

[Nick Roberts]

Simon Wright <simon@pushface.org> wrote:

> Nick Roberts <nick.roberts@acm.org> writes:
> 
> > I think the 'in out' mode would work with GNAT/GCC, but I'd suggest
> > testing it to make sure. I suppose using the 'access' mode might be
> > clearer, and it might be slightly more efficient.
> 
> with Interfaces.C; function Wibble (Number: in out Interfaces.C.int)
> return Interfaces.C.int; pragma Import(C,Wibble,"wibble");
> 
> smaug.pushface.org[4]$ gnatgcc wibble.ads wibble.ads:2:18: functions can
> only have "in" parameters

Of course, that was stupid of me. It must either be a procedure or use an
access parameter. Sorry.

-- 
Nick Roberts

Re: Ada equivalent for C-pointer?

[Pascal Obry]

Nick Roberts <nick.roberts@acm.org> writes:

> Pascal Obry <pascal@obry.net> wrote:
> 
> > I don't think so. Here Number will be passed by value, no?
> 
> No, I don't think so (with GNAT/GCC).

GNAT/GCC is not Ada ;) So for portability reasons it is certainly
wrong. Moreover, are you sure it is the case for all GNAT/GCC targets ?

> it to make sure. I suppose using the 'access' mode might be clearer, and it
> might be slightly more efficient.

Don't know if it is more efficient, but it is portable !

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada equivalent for C-pointer?

[Martin Krischik]

Nick Roberts wrote:

> Pascal Obry <pascal@obry.net> wrote:
> 
>> I don't think so. Here Number will be passed by value, no?
> 
> No, I don't think so (with GNAT/GCC).
> 
>> And you also need the returned value ;)
> 
> Yes, oops!
> 
>> So, you probably want:
>> 
>>     function Wibble (Number: access Interfaces.C.int)
>>           return Interfaces.C.int;
>> 
>>     pragma Import(C,Wibble,"wibble");
> 
> I think the 'in out' mode would work with GNAT/GCC, but I'd suggest
> testing it to make sure.

I did the testing - it does work

> I suppose using the 'access' mode might be 
> clearer, and it might be slightly more efficient.

Anonymous access efficient? If you have a copy read John Barnes Ada 95 (2nd
edition), Page 190, 3rd chapter to end of page.

Yes, I know, it does not apply to export/import C functions.

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada equivalent for C-pointer?

[Pascal Obry]

Martin Krischik <martin@krischik.com> writes:

> >> So, you probably want:
> >> 
> >>     function Wibble (Number: access Interfaces.C.int)
> >>           return Interfaces.C.int;
> >> 
> >>     pragma Import(C,Wibble,"wibble");
> > 
> > I think the 'in out' mode would work with GNAT/GCC, but I'd suggest
> > testing it to make sure.
> 
> I did the testing - it does work

How a function with an "in out" parameter can possibly work :) ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada equivalent for C-pointer?

[Martin Krischik]

Pascal Obry wrote:

> 
> Martin Krischik <martin@krischik.com> writes:
> 
>> >> So, you probably want:
>> >> 
>> >>     function Wibble (Number: access Interfaces.C.int)
>> >>           return Interfaces.C.int;
>> >> 
>> >>     pragma Import(C,Wibble,"wibble");
>> > 
>> > I think the 'in out' mode would work with GNAT/GCC, but I'd suggest
>> > testing it to make sure.
>> 
>> I did the testing - it does work
> 
> How a function with an "in out" parameter can possibly work :) ?

Ok, you got me there. Of corse it will work only with a procedure. But: A
ex/import C function will use a pointer for record types on "in" as well.

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada equivalent for C-pointer?

[Martin Krischik]

Pascal Obry wrote:

> 
> Nick Roberts <nick.roberts@acm.org> writes:
> 
>> For example, if there is a C function defined thus:
>> 
>>    int wibble(int *n);
>> 
>> then in Ada you can declare:
>> 
>>    function Wibble (Number: in out Interfaces.C.int);
>>    pragma Import(C,Wibble,"wibble");
>> 
>> and it should work. (Obviously, you must link the C functions in
>> somehow.)
> 
> I don't think so. Here Number will be passed by value, no? And you also
> need the returned value ;)

No all out and in out parameter are passed as pointer when pragma Import(C
is used - thats unless you use C_Pass_By_Copy. I have written quite a lot
of code interfaceing with C.

Read: 

http://en.wikibooks.org/wiki/Programming:Ada:Types:access#C_compatible_pointer

> So, you probably want:
> 
>     function Wibble (Number: access Interfaces.C.int) return
>     Interfaces.C.int; pragma Import(C,Wibble,"wibble");

No! you don't want that! You would need aliased data then!

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada equivalent for C-pointer?

[Niklas Holsti]

Martin Krischik wrote:
> Pascal Obry wrote:
> 
> 
>>Nick Roberts <nick.roberts@acm.org> writes:
>>
>>
>>>For example, if there is a C function defined thus:
>>>
>>>   int wibble(int *n);
>>>
>>>then in Ada you can declare:
>>>
>>>   function Wibble (Number: in out Interfaces.C.int);
>>>   pragma Import(C,Wibble,"wibble");
>>>
>>>and it should work. (Obviously, you must link the C functions in
>>>somehow.)
>>
>>I don't think so. Here Number will be passed by value, no? And you also
>>need the returned value ;)
> 
> 
> No all out and in out parameter are passed as pointer when pragma Import(C
> is used - thats unless you use C_Pass_By_Copy. I have written quite a lot
> of code interfaceing with C.

But according to LRM B.3(68), for an "in out" parameter of an 
*elementary* type (as here) the pointer that is passed to the C function 
is a pointer to a *temporary copy* of the parameter (here Number), not a 
pointer to the parameter itself. This may not be what the C function 
expects. For example, it would not make sense for "wibble" to save the 
pointer for later use.

(Perhaps this detail is explained in the Wiki page that was referenced. 
For some reason, I couldn't reach that page to read it.)

-- 
Niklas Holsti
Tidorum Ltd

niklas holsti tidorum fi
       .      @       .

Re: Ada equivalent for C-pointer?

[Martin Krischik]

Niklas Holsti wrote:

> Martin Krischik wrote:
>> Pascal Obry wrote:
>> 
>> 
>>>Nick Roberts <nick.roberts@acm.org> writes:
>>>
>>>
>>>>For example, if there is a C function defined thus:
>>>>
>>>>   int wibble(int *n);
>>>>
>>>>then in Ada you can declare:
>>>>
>>>>   function Wibble (Number: in out Interfaces.C.int);
>>>>   pragma Import(C,Wibble,"wibble");
>>>>
>>>>and it should work. (Obviously, you must link the C functions in
>>>>somehow.)
>>>
>>>I don't think so. Here Number will be passed by value, no? And you also
>>>need the returned value ;)
>> 
>> 
>> No all out and in out parameter are passed as pointer when pragma
>> Import(C is used - thats unless you use C_Pass_By_Copy. I have written
>> quite a lot of code interfaceing with C.
> 
> But according to LRM B.3(68), for an "in out" parameter of an
> *elementary* type (as here) the pointer that is passed to the C function
> is a pointer to a *temporary copy* of the parameter (here Number), not a
> pointer to the parameter itself. This may not be what the C function
> expects.

Interesting. I have to think about that. Question is if the optimizer is
allowed to remove the copy.

> For example, it would not make sense for "wibble" to save the 
> pointer for later use.

Well storing a pointer to a stack object is allways wrong. If you want to
store a pointer to the object neither "in out" nor "anomymous access" is
appropiate - a "pool access" should be used instead. And the Ada interface
should reflect that - if only to document propper use.

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada equivalent for C-pointer?

[Niklas Holsti]

Martin Krischik wrote:
> Niklas Holsti wrote:
> 
> 
>>Martin Krischik wrote:
>>
>>>Pascal Obry wrote:
>>>
>>>
>>>
>>>>Nick Roberts <nick.roberts@acm.org> writes:
>>>>
>>>>
>>>>
>>>>>For example, if there is a C function defined thus:
>>>>>
>>>>>  int wibble(int *n);
>>>>>
>>>>>then in Ada you can declare:
>>>>>
>>>>>  function Wibble (Number: in out Interfaces.C.int);
>>>>>  pragma Import(C,Wibble,"wibble");
>>>>>
>>>>>and it should work. (Obviously, you must link the C functions in
>>>>>somehow.)
>>>>
>>>>I don't think so. Here Number will be passed by value, no? And you also
>>>>need the returned value ;)
>>>
>>>
>>>No all out and in out parameter are passed as pointer when pragma
>>>Import(C is used - thats unless you use C_Pass_By_Copy. I have written
>>>quite a lot of code interfaceing with C.
>>
>>But according to LRM B.3(68), for an "in out" parameter of an
>>*elementary* type (as here) the pointer that is passed to the C function
>>is a pointer to a *temporary copy* of the parameter (here Number), not a
>>pointer to the parameter itself. This may not be what the C function
>>expects.
> 
> 
> Interesting. I have to think about that. Question is if the optimizer is
> allowed to remove the copy.

Well, as Nick Roberts pointed out LRM B.3(68) is only implementation 
advice, so to copy, or not to copy, is up to the implementation.

>>For example, it would not make sense for "wibble" to save the 
>>pointer for later use.
> 
> 
> Well storing a pointer to a stack object is allways wrong.

No -- it's only wrong (in the sense of "does not work") to *use* such a 
pointer after the containing stack frame has returned. In this example, 
the stack frame that contains "Number" may exist for several calls of 
"wibble" or other C functions in the same library, and "wibble" might 
want to store the pointer somewhere (perhaps in an equally temporary 
data structure) for use by the other functions in the library. I've seen 
C libraries that do things like that, and it works, but of course it 
increases the risk that programming errors lead to use of invalid 
(dangling) pointers.

> If you want to
> store a pointer to the object neither "in out" nor "anomymous access" is
> appropiate - a "pool access" should be used instead. And the Ada interface
> should reflect that - if only to document propper use.

I agree that "pool access" is a better solution when the C routine 
stores the pointer for a "long" time.

-- 
Niklas Holsti
Tidorum Ltd

niklas holsti tidorum fi
       .      @       .

Re: Ada equivalent for C-pointer?

[Nick Roberts]

Niklas Holsti <nobody@nowhere.fi> wrote:

> But according to LRM B.3(68), for an "in out" parameter of an *elementary*
> type (as here) the pointer that is passed to the C function is a pointer
> to a *temporary copy* of the parameter (here Number), not a pointer to the
> parameter itself. This may not be what the C function expects. For
> example, it would not make sense for "wibble" to save the pointer for
> later use.
> 
> (Perhaps this detail is explained in the Wiki page that was referenced.
> For some reason, I couldn't reach that page to read it.)

I think the idea is as follows. Supposing a call is made to Wibble with an 
actual parameter corresponding to Number called Actual. The call first makes
a copy of the value of Actual, then it passes a pointer to that copy as the
parameter Number, and makes the call. Upon return, the value in that
temporary copy is then copied back into Actual. (Hence, it 'works' :-)

The idea is that Actual may, in fact, be a register, or something other than
a straightforward memory location. The temporary copy will be in a
straightforward memory location (suitable to be pointed at by a C pointer).
However, I suspect a possible optimisation, if it so happens that Actual is
in fact stored in a straightforward memory location, is to simply pass a
pointer to Actual; theoretically, the semantics should be the same (in the
absence of aliasing effects).

However, this is all based upon an Implementation Advice clause.
Implementations are necessarily permitted to do something else.

-- 
Nick Roberts

Re: Ada equivalent for C-pointer?

[Randy Brukardt]

"Pascal Obry" <pascal@obry.net> wrote in message
news:u651y3bfs.fsf@obry.net...
>
> Nick Roberts <nick.roberts@acm.org> writes:
>
> > For example, if there is a C function defined thus:
> >
> >    int wibble(int *n);
> >
> > then in Ada you can declare:
> >
> >    function Wibble (Number: in out Interfaces.C.int);
> >    pragma Import(C,Wibble,"wibble");
> >
> > and it should work. (Obviously, you must link the C functions in
somehow.)
>
> I don't think so. Here Number will be passed by value, no? And you also
need
> the returned value ;)

Go re-read B.3(63-71). In this case, specifically B.3(68). Now, that is only
"advice", but compilers are strongly encouraged to follow "advice", and I
think that they all do in this area. (Otherwise, Claw wouldn't have been
possible - we use the same pragma Imports for all of the compilers.)

                         Randy.

Re: Ada equivalent for C-pointer?

[Pascal Obry]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Go re-read B.3(63-71). In this case, specifically B.3(68). Now, that is only

Thanks for the pointers, I was wrong indeed!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada equivalent for C-pointer?

[Alfred Hilscher]

Alfred Hilscher schrieb:
> 
> I want to interface to a C-function expecting a "far *", what have I to
> pass: an "access all ..." or "System.Address"? Are there differences
> between access and address, or are their internal representations equal?
> I use GNAT 3.15p.
> 
> 
> -----------------------------------------------------
> To send me mail, please replace "Spam" by "Jedermann"
> -----------------------------------------------------

Thanks to all of you. What I do is to write some bindings for a windows
dll. The C-header looks like this: int function (far *xy); As Nick
stated, in the flat model of windows a "far" and a "near" would be the
same. So I will declare it as an "access" type (ev. with the "pragma
Convention (C, C_Pointer);").

Re: Ada equivalent for C-pointer?

[Keith Thompson]

Alfred Hilscher <SPAM@alfred-hilscher.de> writes:
[...]
> Thanks to all of you. What I do is to write some bindings for a windows
> dll. The C-header looks like this: int function (far *xy); As Nick
> stated, in the flat model of windows a "far" and a "near" would be the
> same. So I will declare it as an "access" type (ev. with the "pragma
> Convention (C, C_Pointer);").

Are you sure the C declaration looks like

    int function(far *xy);

?  That's a syntax error even for C compilers that support "far"
pointers.  It might be something like

    int function(int far *xy);

Since (as I understand it) "far" doesn't mean anything on modern
systems, it's quite likely that your C compiler either ignores the
"far" keyword or a header "#define"s it as nothing.

See what your C compiler's documentation says about "far" pointers.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.