Re: aliased and parameters

["REH" <me@you.com>]

"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