aliased and parameters

aliased and parameters

[REH]

Is there a way to indicate to the compiler that a parameter should be
aliased?  Our software has a client/server library build on sockets.
This library has API that take parameters of a particular type (i.e.,
defined headers) and call socket API internally to send/receive the
data.  For example:

procedure Receive(Hdr : out Header_Type) is
begin
...
recv(socket, Hdr'Address, header_size);
...
end;

The problem is that some Ada95 compiler are so aggressive with
optimization that they may not "see" then Hdr is changed by recv.  At
the very less the compiler complains (rightfully so) that Hdr is alised
but not marked as such.  But how do enforce that if I cannot define the
parameter as aliased?  Should I use an access type instead and convert
it to System.Address, or is there a cleaner way?

Thanks,
REH

Re: aliased and parameters

[Jeffrey R. Carter]

REH wrote:
> ...
> recv(socket, Hdr'Address, header_size);
> 
> The problem is that some Ada95 compiler are so aggressive with
> optimization that they may not "see" then Hdr is changed by recv.  At
> the very less the compiler complains (rightfully so) that Hdr is alised
> but not marked as such.  But how do enforce that if I cannot define the
> parameter as aliased?  Should I use an access type instead and convert
> it to System.Address, or is there a cleaner way?

You should not be using 'Address at all. I don't know the definition of 
Recv, so I can't say what would be better. If it's an interface to C, 
you might want an array or a C-compatible access value.

Of course, that assumes you can change the library in question.

-- 
Jeff Carter
"Death awaits you all, with nasty, big, pointy teeth!"
Monty Python & the Holy Grail
20

Re: aliased and parameters

[REH]

Jeffrey R. Carter wrote:
> REH wrote:
> > ...
> > recv(socket, Hdr'Address, header_size);
> >
> > The problem is that some Ada95 compiler are so aggressive with
> > optimization that they may not "see" then Hdr is changed by recv.  At
> > the very less the compiler complains (rightfully so) that Hdr is alised
> > but not marked as such.  But how do enforce that if I cannot define the
> > parameter as aliased?  Should I use an access type instead and convert
> > it to System.Address, or is there a cleaner way?
>
> You should not be using 'Address at all. I don't know the definition of
> Recv, so I can't say what would be better. If it's an interface to C,
> you might want an array or a C-compatible access value.
>
> Of course, that assumes you can change the library in question.
>
> --
> Jeff Carter
> "Death awaits you all, with nasty, big, pointy teeth!"
> Monty Python & the Holy Grail
> 20

Thanks Jeff.  recv is the standard POSIX (or BSD) socket receive
function.  It takes a pointer.  Yes, I could use an array (as I could
still map it to a C pointer).  The problem with this is I either have
to move the data from its "normal" type into the array (excessive data
movement) or I have to map the array over top of my data (which gets us
right back to using 'Address).

REH

Re: aliased and parameters

[REH]

randomm@mindless.com wrote:
> X-No-Archive: Yes
>
> > Thanks Jeff.  recv is the standard POSIX (or BSD) socket receive
> > function.  It takes a pointer.  Yes, I could use an array (as I could
> > still map it to a C pointer).  The problem with this is I either have
> > to move the data from its "normal" type into the array (excessive data
> > movement) or I have to map the array over top of my data (which gets us
> > right back to using 'Address).
> >
> > REH
>
> What about using pragma volatile(Hdr)?  If I understand correctly, it
> may be the answer here.  See RM95 C.6.
>
> Regards,
> Randall

Great!  Can I use that on a subprogram parameter.  Like this?

procedure Foo(X : out Integer) is
  pragma Volatile(X);
begin
...

REH

Re: aliased and parameters

[REH]

REH wrote:
> Great!  Can I use that on a subprogram parameter.  Like this?
>
> procedure Foo(X : out Integer) is
>   pragma Volatile(X);
> begin
> ...
>
> REH

No dice.  The compiler says the above volates 13.14(19) of the standard
(A representation item cannot be specified for an entity that has
already been frozen)

I think I can do this, though:

type Header_Type is ...
pragma Volatile(Header_Type);

procedure Foo(Hdr : out Header_Type) is ...


REH

Re: aliased and parameters

[Björn Persson]

REH wrote:
> recv is the standard POSIX (or BSD) socket receive
> function.

Can't you import recv like this?

function Recv(Socket : in  int;
               Hdr    : out Header_Type;
               Size   : in  size_t;
               Flags  : in  int);
pragma Import(C, Recv, "recv");

This should work if your compiler follows the advice in ARM95 B.3, and 
you won't have to mess with 'Address or pragma Volatile. You should be 
able to make multiple imports like this, with different types instead of 
the void pointer.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: aliased and parameters

[REH]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]


"Bj�rn Persson" <spam-away@nowhere.nil> wrote in message 
news:tYuzg.11401$E02.3978@newsb.telia.net...
> REH wrote:
>> recv is the standard POSIX (or BSD) socket receive
>> function.
>
> Can't you import recv like this?
>
> function Recv(Socket : in  int;
>               Hdr    : out Header_Type;
>               Size   : in  size_t;
>               Flags  : in  int);
> pragma Import(C, Recv, "recv");
>
> This should work if your compiler follows the advice in ARM95 B.3, and you 
> won't have to mess with 'Address or pragma Volatile. You should be able to 
> make multiple imports like this, with different types instead of the void 
> pointer.
>
> -- 
> Bj�rn Persson                              PGP key A88682FD
>                    omb jor ers @sv ge.
>                    r o.b n.p son eri nu

That's a good idea, thank you.

REH

Re: aliased and parameters

[Jeffrey R. Carter]

REH wrote:
> 
> Thanks Jeff.  recv is the standard POSIX (or BSD) socket receive
> function.  It takes a pointer.  Yes, I could use an array (as I could
> still map it to a C pointer).  The problem with this is I either have
> to move the data from its "normal" type into the array (excessive data
> movement) or I have to map the array over top of my data (which gets us
> right back to using 'Address).

I was referring to the Ada library, not the C library (in this case). 
There is, for example, a standard Ada binding to POSIX. Are you using 
it, or are you making your own binding? If the latter, you should 
probably consider the former. You might also want to look into 
AdaSockets, which is a fairly platform-independent binding to sockets.

In any case, System.Address is not a pointer. There are compilers where 
a pointer and an Address are the same; there are others where they are 
different. If portability is an issue, you should not pass an address.

Using an address to achieve an overlay is a different matter. This is a 
perfectly portable use of addresses, but not one that is recommended.

If you are building your own binding (probably not a good idea), then 
you can import the function using an out mode parameter of the desired 
type, as suggested elsewhere. If, as is likely, you need to receive many 
different types, you can write a generic to create the bindings.

-- 
Jeff Carter
"I like it when the support group complains that they have
insufficient data on mean time to repair bugs in Ada software."
Robert I. Eachus
91

Re: aliased and parameters

[REH]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message 
news:N9yzg.111006$1i1.103407@attbi_s72...
> REH wrote:
>>
>> Thanks Jeff.  recv is the standard POSIX (or BSD) socket receive
>> function.  It takes a pointer.  Yes, I could use an array (as I could
>> still map it to a C pointer).  The problem with this is I either have
>> to move the data from its "normal" type into the array (excessive data
>> movement) or I have to map the array over top of my data (which gets us
>> right back to using 'Address).
>
> I was referring to the Ada library, not the C library (in this case). 
> There is, for example, a standard Ada binding to POSIX. Are you using it, 
> or are you making your own binding? If the latter, you should probably 
> consider the former. You might also want to look into AdaSockets, which is 
> a fairly platform-independent binding to sockets.

I wasn't aware there was a standard binding.  I am using some binding for 
Integrity that GHS has in their examples, but I was plaining on modifying 
them with better typing.

>
> In any case, System.Address is not a pointer. There are compilers where a 
> pointer and an Address are the same; there are others where they are 
> different. If portability is an issue, you should not pass an address.

I know that, thanks.  The reason I am using Address (and the ONLY time I use 
it) is situation where I need a generic pointer (and I am using a system 
where it maps correctly to C pointers) and am talking to C.  Such situation 
as a send or receive of raw data over a transport such as sockets.  I didn't 
want to have to define a binding for every type I need to send/receive, but 
it looks like it may be my own way around my issue (nor do I want to have to 
instantiate one everytime from a generic).  I never use address within Ada, 
but sometimes it seems to be the cleanest way to talk to the OS.  At least 
it was with '83.  '95's new aliasing rules threw a monkey wrench into that 
(though, I know it's for the better).  Also, binding are fine for the types 
I know about, but my group provides middleware for the applications.  Part 
of the middleware is bindings to the OS.  For sockets and such that can and 
do send any type of data, Address seems cleaner than forcing them to 
instanitate the call for every type they send with sockets (which--knowing 
them--they would probably balk at).  But at least in that situation, the 
compiler will complain to *them* that they are taking the address of 
non-aliased and non-volatile variables!

Too bad Ada doesn't have a generic access type, just for talking with C. 
That would force any variable used to be aliased, avoid any portability 
issues with using Address for pointers, and without a proliferation of 
multiple binding and/or instantiations.


>
> Using an address to achieve an overlay is a different matter. This is a 
> perfectly portable use of addresses, but not one that is recommended.
>
Tell that to GHS.  Their compiler is raising havoc with the application 
group's overlays, even rep. spec'd ones!  Oh well, serves 'em right for 
doing such a thing.

> If you are building your own binding (probably not a good idea), then you 
> can import the function using an out mode parameter of the desired type, 
> as suggested elsewhere. If, as is likely, you need to receive many 
> different types, you can write a generic to create the bindings.

Well, whether or not it's a good idea is moot.  None exist to talk to our 
BSP or OS.  So, I have to write them.  Which is fine.  It's not hard.  I've 
had to do it with many system.  The only problem I've every had was the 
above, and only with one compiler.

REH