Access and alias

Access and alias

[NANCY HEHIR]

I don't understand my compile error and am having trouble finding help in
GNAT or Annotated Reference Manual.

Can anyone explain what's going wrong here, please ?
I am trying to assign an initial address to an access variable.....

type LPDCB is access all DCB;
.
.
DCB_1:DCB;
.
.
DCB_Access:LPDCB := DCB'Access;

compiler generates error 'prefix of "Access" attribute must be aliased'

Re: Access and alias

[tmoran]

> DCB_Access:LPDCB := DCB'Access;

  This says you want the variable DCB_Access to point to DCB, which is
a *type*.  You probably meant it to point to an *object* of type DCB,
in particular, the object DCB_1, so you need to say:
  DCB_Access:LPDCB := DCB_1'Access;
Also, in order to have anything point at DCB_1, you are required to
announce in public that there may be ways to modify object DBC_1
other than via the name "DCB_1", ie, DCB_1 may have aliases.  Say
  DCB_1: aliased DCB;
and then the compiler will let you make pointers to DCB_1.

Re: Access and alias

[NANCY HEHIR]

I am trying to use SetCommState to configure a Comm Port.
I have created a handle for COM1 using CreateFile.
SetCommState takes as it's parameters the handle and a type LPDCB (access to
the DCB)
The type LPDCB is defined in Win32-winbase.ads

Thanks for your help

Laurent Guerby wrote in message
<86d7o5ae23.fsf@ppp-169-201.villette.club-internet.fr>...

>
>Try:
>
> DCB_1 : aliased DCB;
>
>> .
>> .
>> DCB_Access:LPDCB := DCB'Access;
>>
>> compiler generates error 'prefix of "Access" attribute must be aliased'
>
>However, it is very "rare" in Ada to use aliased variables, if you're
>from a C background and try to write Ada like you write C I think
>adding "aliased" and "'access" everywhere is not the right thing to
>do. A possible guess is that you are emulating the use of "&" in C
>with aliased/access, and that the right way to do it in Ada is to use
>the "in out" parameter mode.
>
>May be if you tell us more about what you're trying to do, we can
>suggest appropriate Ada idioms (note that may be the use of aliased
>and access is the appropriate idiom here ;-).
>
>--LG

Re: Access and alias

[Laurent Guerby]

"NANCY HEHIR" <nanceh.ennis@tinet.ie> writes:
> I don't understand my compile error and am having trouble finding help in
> GNAT or Annotated Reference Manual.
> 
> Can anyone explain what's going wrong here, please ?
> I am trying to assign an initial address to an access variable.....
> 
> type LPDCB is access all DCB;
> .
> .
> DCB_1:DCB;

Try:

 DCB_1 : aliased DCB;

> .
> .
> DCB_Access:LPDCB := DCB'Access;
> 
> compiler generates error 'prefix of "Access" attribute must be aliased'

However, it is very "rare" in Ada to use aliased variables, if you're
from a C background and try to write Ada like you write C I think
adding "aliased" and "'access" everywhere is not the right thing to
do. A possible guess is that you are emulating the use of "&" in C
with aliased/access, and that the right way to do it in Ada is to use
the "in out" parameter mode.

May be if you tell us more about what you're trying to do, we can
suggest appropriate Ada idioms (note that may be the use of aliased
and access is the appropriate idiom here ;-).

--LG

Re: Access and alias

[Laurent Guerby]

"NANCY HEHIR" <nanceh.ennis@tinet.ie> writes:

> I am trying to use SetCommState to configure a Comm Port.
> I have created a handle for COM1 using CreateFile.
> SetCommState takes as it's parameters the handle and a type LPDCB (access to
> the DCB)
> The type LPDCB is defined in Win32-winbase.ads

Okay, win32, I see now, no way around this major braindamage then ;-).

Last time I had to use the Win32 API, I manually imported the needed
entries (a dozen) using System.Address as parameter type and 'Address
on various things on the caller side. This way I avoided the
dependency on the Win32 binding hierarchy, hence easier build process.
Of course, after a dozen functions, I'd switch to use the Win32
binding.

> Thanks for your help

You're welcome.

--LG

Re: Access and alias

[Alfred Hilscher]

Laurent Guerby wrote:
> 
> "NANCY HEHIR" <nanceh.ennis@tinet.ie> writes:
> 
> > I am trying to use SetCommState to configure a Comm Port.
> > I have created a handle for COM1 using CreateFile.
> > SetCommState takes as it's parameters the handle and a type LPDCB (access to
> > the DCB)
> > The type LPDCB is defined in Win32-winbase.ads
> 
> Okay, win32, I see now, no way around this major braindamage then ;-).
> 
> Last time I had to use the Win32 API, I manually imported the needed
> entries (a dozen) using System.Address as parameter type and 'Address
> on various things on the caller side. This way I avoided the
> dependency on the Win32 binding hierarchy, hence easier build process.
> Of course, after a dozen functions, I'd switch to use the Win32
> binding.

If you write your own bindings, you shouldn't work with 'address. Use an
in out parameter instead. 
E.g. proc (ref : SYSTEM.ADDRESS); --> proc (ref : in out X);

Re: Access and alias

[Ted Dennison]

In article <38EB55AE.D4A241FD@icn.siemens.de>,
  Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote:
> If you write your own bindings, you shouldn't work with 'address. Use
> an in out parameter instead.
> E.g. proc (ref : SYSTEM.ADDRESS); --> proc (ref : in out X);

...unless you are writing a binding to a function, in which case you are
back to using addresses.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Access and alias

[Jeffrey D. Cherry]

I haven't tested the following procedure, but it should work.  You'll have to 
supply the necessary code to modify the device control block fields the way 
you want.  The procedure also demonstrates one way of using the Win32 API 
without resorting to 'address attributes.  I prefer this method since it 
explicitly shows that I'm performing an unchecked operation, and messing 
around with addresses.  Let me know if/how it works.

-- file Change_Comm_State.ads
with Win32.Winbase;
with Win32.Winnt;

procedure Change_Comm_State(
   Handle : in     Win32.Winnt.HANDLE;
   Status :    out Win32.DWORD);

-- file Change_Comm_State.adb
with Win32.Winerror;

procedure Change_Comm_State(
   Handle : in     Win32.Winnt.HANDLE;
   Status :    out Win32.DWORD) is

use type Win32.BOOL;

   Device_Control_Block : aliased Win32.Winbase.DCB;
   Result               : Win32.BOOL;

begin -- Change_Comm_State
   Status := Win32.Winerror.NO_ERROR;

   -- Get the current state of the comm device.
   Result := Win32.Winbase.GetCommState(Handle,
         Device_Control_Block'unchecked_access);
   if Result = Win32.FALSE then
      Status := Win32.Winbase.GetLastError;

   else
      -- Modify Device_Control_Block as necessary.
      -- Set the comm device state.
      Result := Win32.Winbase.SetCommState(Handle,
            Device_Control_Block'unchecked_access);
      if Result = Win32.FALSE then
         Status := Win32.Winbase.GetLastError;
      end if;
   end if;
end Change_Comm_State;

-- 
Regards,
Jeffrey D. Cherry
Senior IV&V Analyst
Logicon Space and Information Operations
Logicon Inc.
a Northrop Grumman company

Re: Access and alias

[Jeff Carter]

Ted Dennison wrote:
> 
> In article <38EB55AE.D4A241FD@icn.siemens.de>,
>   Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote:
> > If you write your own bindings, you shouldn't work with 'address. Use
> > an in out parameter instead.
> > E.g. proc (ref : SYSTEM.ADDRESS); --> proc (ref : in out X);
> 
> ...unless you are writing a binding to a function, in which case you are
> back to using addresses.

If you have to pass null, access types (with convention C) work fine. If
you don't have to pass null, in out works for procedures, and access
parameters work for functions. All keep the type checking that addresses
lose:

-- int func (int* I);

function F1 (I : System.Address) return Int;
pragma Import (C, F1, "func");

function F2 (I : access Int) return Int;
pragma Import (C, F2, "func");

I : aliased Int;
J : Int;
S : String := Get;

...

J := F1 (I'Address); -- works as intended
J := F1 (S'Address); -- works as not intended
J := F2 (I'access); -- works as intended
J := F2 (S'access); -- compilation error

-- 
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail

Re: Access and alias

[Laurent Guerby]

Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> writes:
> If you write your own bindings, you shouldn't work with 'address. Use an
> in out parameter instead. 
> E.g. proc (ref : SYSTEM.ADDRESS); --> proc (ref : in out X);

In general I agree, but in the Win32 API case, most parameters are at
the C pointer level and NULL has a special effect, so you cannot bind
with "in out".

--LG

Re: Access and alias

[tmoran]

> > E.g. proc (ref : SYSTEM.ADDRESS); --> proc (ref : in out X);
>
> ...unless you are writing a binding to a function, in which case you are
> back to using addresses.
  As I understand it, if a function has an access type as a parameter,
and has a "pragma import", then the compiler is required to do whatever
might be necessary to convert its idea of an access value in Ada to
the called language's idea of an access value.  Is there also a
requirement that it convert its idea of a System.Address into the
called language's idea of an access value?

Re: Access and alias

[Alfred Hilscher]

Jeff Carter wrote:
> If you have to pass null, access types (with convention C) work fine. If
> you don't have to pass null, in out works for procedures, and access
> parameters work for functions. All keep the type checking that addresses
> lose:
> 
> -- int func (int* I);
> 
> function F1 (I : System.Address) return Int;
> pragma Import (C, F1, "func");
> 
> function F2 (I : access Int) return Int;
> pragma Import (C, F2, "func");
> 
> I : aliased Int;
> J : Int;
> S : String := Get;
> 
> ...
> 
> J := F1 (I'Address); -- works as intended
> J := F1 (S'Address); -- works as not intended
> J := F2 (I'access); -- works as intended
> J := F2 (S'access); -- compilation error

OK. But I would do a little change:

Instead of:
function F2 (I : access Int) return Int;
pragma Import (C, F2, "func");

Would write
type Int_Access is access all INT;
function F2 (I : Int_Access) return Int;
pragma Import (C, F2, "func");

This avoids some problems that I had with anonymous access types.

Re: Access and alias

[Robert Dewar]

In article <8cfnpd$3h7$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> ...unless you are writing a binding to a function, in which
> case you are back to using addresses.


Or you can use the Import_Valued_Procedure pragma available in
DEC Ada and in GNAT.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Access and alias

[Robert Dewar]

In article <38EBBBBE.87C93900@acm.org>,
  jrcarter@acm.org wrote:
> If you have to pass null, access types (with convention C)
> work fine.

I would not agree with the word fine, this usage means that
you end up overusing aliased variables. Acceptable, yes,
fine, no!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Access and alias

[tmoran]

>If the compiler DID use a different representation for the
>two, I would say your prescription would be quite wrong, there
>is absolutely no requirement in the RM for such conversions,
>and pragmatically it would be a bad idea to molest parameters
>in this way.

So the effect of a pragma import on a function's parameters
should not be to generate any code, but merely to check that the
parameters' types are "compatible" between the external language
and the Ada compiler?  For

  type Matrix is array(1 .. 10, 1 .. 5) of float;
  type pconstrained is access matrix;
  type List is array(integer range <>) of float;
  type punconstrained is access List;

  function cf(a : pconstrained; b : punconstrained) return float;
  pragma import(C, cf);

Gnat 3.12p NT does indeed generate a nice diagnostic
"type of cf.b does not correspond to C pointer".

But it gives no warning for

  function Trace(M : in Matrix) return float;
  pragma import(Fortran, Trace);

where of course Matrix is stored in one way in Ada and another
in Fortran.  Is this disparity just B.1(20)'s "The implementation
permits T as an L-compatible type" with Gnat permitting
Matrix but not punconstrained?

The other part of the post was:
>Is there also a requirement that it convert its idea of a
>System.Address into the called language's idea of an access value?

So the compiler should not convert System.Address to char *p,
but may either permit it or flag it as it sees fit,  with no
required relationship to whether their memory representations
match?

Re: Access and alias

[Jeff Carter]

Alfred Hilscher wrote:
> 
> Jeff Carter wrote:
> > If you have to pass null, access types (with convention C) work fine. If
> > you don't have to pass null, in out works for procedures, and access
> > parameters work for functions. All keep the type checking that addresses
> > lose:
> >
> > -- int func (int* I);
> >
> > function F1 (I : System.Address) return Int;
> > pragma Import (C, F1, "func");
> >
> > function F2 (I : access Int) return Int;
> > pragma Import (C, F2, "func");
> >
> > I : aliased Int;
> > J : Int;
> > S : String := Get;

I see I forgot to put "aliased" on the declaration of S. Sorry.

> >
> > ...
> >
> > J := F1 (I'Address); -- works as intended
> > J := F1 (S'Address); -- works as not intended
> > J := F2 (I'access); -- works as intended
> > J := F2 (S'access); -- compilation error
> 
> OK. But I would do a little change:
> 
> Instead of:
> function F2 (I : access Int) return Int;
> pragma Import (C, F2, "func");
> 
> Would write
> type Int_Access is access all INT;
> function F2 (I : Int_Access) return Int;
> pragma Import (C, F2, "func");
> 
> This avoids some problems that I had with anonymous access types.

Yes, if you have to pass null, this is the way to do it. BE sure to put
a

pragma Convention (C, Int_Access)

in there. Then you declare

P : Int_Access;

...

J := F2 (P);

and presumably the C function knows what to do with the null.


-- 
Jeff Carter
"We burst our pimples at you."
Monty Python & the Holy Grail

Re: Access and alias

[Jeff Carter]

Robert Dewar wrote:
> 
> In article <38EBBBBE.87C93900@acm.org>,
>   jrcarter@acm.org wrote:
> > If you have to pass null, access types (with convention C)
> > work fine.
> 
> I would not agree with the word fine, this usage means that
> you end up overusing aliased variables. Acceptable, yes,
> fine, no!

Yes, you end up with aliased variables, but hopefully the C function is
wrapped inside a subprogram that converts between the C types and
application-specific Ada types, so the aliasing is confined to that
subprogram.

-- 
Jeff Carter
"We burst our pimples at you."
Monty Python & the Holy Grail

Re: Access and alias

[Robert Dewar]

In article <J77H4.418$Qy3.109837@news.pacbell.net>,
  tmoran@bix.com wrote:

> As I understand it, if a function has an access type as a
> parameter, and has a "pragma import", then the compiler is
> required to do whatever might be necessary to convert its idea
> of an access value in Ada to the called language's idea of an
> access value.

This is actually quite wrong from a pure language point of
view, there is absolutely no reason why a convention Ada
access type should look anything like a pointer.

What you say above is strictly only true if the type is
declared to have Convention C on the Ada side.

If the compiler DID use a different representation for the
two, I would say your prescription would be quite wrong, there
is absolutely no requirement in the RM for such conversions,
and pragmatically it would be a bad idea to molest parameters
in this way.

In practice compilers usually use the same representation for
convention Ada and convention C access values, at least for
all cases except pointer-to-unconstrained, so the issue of
conversion does not arise, and that is probably where Tom's
misunderstanding comes from (i.e. this pretty serious
misunderstanding does not affect things most of the time).



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Access and alias

[Robert Dewar]

In article <K5rH4.445$uE2.158283@news.pacbell.net>,
  tmoran@bix.com wrote:

> So the effect of a pragma import on a function's parameters
> should not be to generate any code, but merely to check that
> the parameters' types are "compatible" between the external
> language and the Ada compiler?

Where do you get that from? There is no requirement in the RM
for such a check, and indeed it would be very annoying, since
obviously for example C is quite capable of handling any
possible Ada parameter at the other end if parameters are
passed in a manner consistent with the ABI.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Access and alias

[tmoran]

> > language and the Ada compiler?
>
> Where do you get that from? There is no requirement in the RM
> for such a check, and indeed it would be very annoying, since
> obviously for example C is quite capable of handling any
> possible Ada parameter at the other end if parameters are
> passed in a manner consistent with the ABI.

The question in the post continued:

>> language and the Ada compiler?  For
>>
>>   type Matrix is array(1 .. 10, 1 .. 5) of float;
>>   type pconstrained is access matrix;
>>   type List is array(integer range <>) of float;
>>   type punconstrained is access List;
>>
>>   function cf(a : pconstrained; b : punconstrained) return float;
>>   pragma import(C, cf);
>>
>> Gnat 3.12p NT does indeed generate a nice diagnostic
>> "type of cf.b does not correspond to C pointer".
>>
>> But it gives no warning for
>>
>>   function Trace(M : in Matrix) return float;
>>   pragma import(Fortran, Trace);
>>
>> where of course Matrix is stored in one way in Ada and another
>> in Fortran.  Is this disparity just B.1(20)'s "The implementation
>> permits T as an L-compatible type" with Gnat permitting
>> Matrix but not punconstrained?

> for example C is quite capable of handling any possible Ada parameter

In that case, what, if anything, does RM B.1 (26) "For an imported or
exported subprogram, the result and parameter types shall each be
compatible with the convention specified in the corresponding program."
require of the compiler?

Re: Access and alias

[Jack W. Sharer]

The following code does not compile. Why?  How do I fix it?

with Interfaces.C.Strings; use Interfaces.C.Strings;
procedure Test_Access is
   procedure EngOutputBuffer ( OutputBuffer: in Chars_Ptr );
   pragma Import ( C, EngOutputBuffer, "engOutputBuffer" );
   Matlab_Output: aliased Interfaces.C.Char_Array(1..50000);
begin
   EngOutputBuffer ( To_Chars_Ptr ( Matlab_Output'Access ) );
end Test_Access;

The compiler is gnat under Sun Solaris.
The compiler generated messages are
   warning: aliased object has explicit bounds
   warning: declare with explicit initialization
   warning: for use with unconstrained access
   object subtype must statically match designated subtype