* aliased and parameters @ 2006-07-31 18:05 REH 2006-07-31 18:37 ` Jeffrey R. Carter 0 siblings, 1 reply; 9+ messages in thread From: REH @ 2006-07-31 18:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: aliased and parameters 2006-07-31 18:05 aliased and parameters REH @ 2006-07-31 18:37 ` Jeffrey R. Carter 2006-07-31 19:02 ` REH 0 siblings, 1 reply; 9+ messages in thread From: Jeffrey R. Carter @ 2006-07-31 18:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: aliased and parameters 2006-07-31 18:37 ` Jeffrey R. Carter @ 2006-07-31 19:02 ` REH [not found] ` <1154373046.777655.292010@m79g2000cwm.googlegroups.com> ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: REH @ 2006-07-31 19:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <1154373046.777655.292010@m79g2000cwm.googlegroups.com>]
* Re: aliased and parameters [not found] ` <1154373046.777655.292010@m79g2000cwm.googlegroups.com> @ 2006-07-31 19:26 ` REH 2006-07-31 19:59 ` REH 0 siblings, 1 reply; 9+ messages in thread From: REH @ 2006-07-31 19:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: aliased and parameters 2006-07-31 19:26 ` REH @ 2006-07-31 19:59 ` REH 0 siblings, 0 replies; 9+ messages in thread From: REH @ 2006-07-31 19:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: aliased and parameters 2006-07-31 19:02 ` REH [not found] ` <1154373046.777655.292010@m79g2000cwm.googlegroups.com> @ 2006-07-31 21:52 ` Björn Persson 2006-08-01 0:35 ` REH 2006-08-01 1:31 ` Jeffrey R. Carter 2 siblings, 1 reply; 9+ messages in thread From: Björn Persson @ 2006-07-31 21:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: aliased and parameters 2006-07-31 21:52 ` Björn Persson @ 2006-08-01 0:35 ` REH 0 siblings, 0 replies; 9+ messages in thread From: REH @ 2006-08-01 0:35 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: aliased and parameters 2006-07-31 19:02 ` REH [not found] ` <1154373046.777655.292010@m79g2000cwm.googlegroups.com> 2006-07-31 21:52 ` Björn Persson @ 2006-08-01 1:31 ` Jeffrey R. Carter 2006-08-01 2:28 ` REH 2 siblings, 1 reply; 9+ messages in thread From: Jeffrey R. Carter @ 2006-08-01 1:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: aliased and parameters 2006-08-01 1:31 ` Jeffrey R. Carter @ 2006-08-01 2:28 ` REH 0 siblings, 0 replies; 9+ messages in thread From: REH @ 2006-08-01 2:28 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-08-01 2:28 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-07-31 18:05 aliased and parameters REH 2006-07-31 18:37 ` Jeffrey R. Carter 2006-07-31 19:02 ` REH [not found] ` <1154373046.777655.292010@m79g2000cwm.googlegroups.com> 2006-07-31 19:26 ` REH 2006-07-31 19:59 ` REH 2006-07-31 21:52 ` Björn Persson 2006-08-01 0:35 ` REH 2006-08-01 1:31 ` Jeffrey R. Carter 2006-08-01 2:28 ` REH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox