* How do I get this to work?? @ 1999-01-04 0:00 Chris Warwick 1999-01-05 0:00 ` Chris Warwick 1999-01-05 0:00 ` Tom Moran 0 siblings, 2 replies; 55+ messages in thread From: Chris Warwick @ 1999-01-04 0:00 UTC (permalink / raw) package Ada_Front_End is type Session_Type is record Status : integer := 0; end record; type Session_Ptr_Type is access Session_Type; function Close_Port (Session : in Session_Ptr_Type) return integer; end Ada_Front_End; procedure Close_Connection is Session : aliased constant Ada_Front_End.Session_Type; Session_Ptr : Session_Ptr_Type := Session'Access; begin Ada_Front_End.Close_Port (Session => Session_Ptr); end Close_Connection; ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-04 0:00 How do I get this to work?? Chris Warwick @ 1999-01-05 0:00 ` Chris Warwick 1999-01-05 0:00 ` Stephen Leake ` (2 more replies) 1999-01-05 0:00 ` Tom Moran 1 sibling, 3 replies; 55+ messages in thread From: Chris Warwick @ 1999-01-05 0:00 UTC (permalink / raw) Sorry, perhaps I should have been a little more specific... Chris Warwick wrote in message <76s0dp$1v4$1@nntp3.uunet.ca>... > package Ada_Front_End is > > type Session_Type is > record > Status : integer := 0; > end record; > > type Session_Ptr_Type is access Session_Type; > > function Close_Port (Session : in Session_Ptr_Type) return integer; > end Ada_Front_End; > > procedure Close_Connection is > Session : aliased constant Ada_Front_End.Session_Type; > Session_Ptr : Session_Ptr_Type := Session'Access; It barfs here, because Session_Ptr_Type has greater scope than Session. My problem is Close_Port needs a pointer to a Session, so I have to define the Session_Ptr_Type at the highest level... > begin > Ada_Front_End.Close_Port > (Session => Session_Ptr); > end Close_Connection; > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-05 0:00 ` Chris Warwick @ 1999-01-05 0:00 ` Stephen Leake 1999-01-05 0:00 ` Tom Moran ` (2 more replies) 1999-01-06 0:00 ` Simon Wright 1999-01-22 0:00 ` Nick Roberts 2 siblings, 3 replies; 55+ messages in thread From: Stephen Leake @ 1999-01-05 0:00 UTC (permalink / raw) "Chris Warwick" <chris.warwick@cdcgy.com> writes: > > package Ada_Front_End is > > > > type Session_Type is > > record > > Status : integer := 0; > > end record; > > > > type Session_Ptr_Type is access Session_Type; > > > > function Close_Port (Session : in Session_Ptr_Type) return integer; > > end Ada_Front_End; > > > > procedure Close_Connection is > > Session : aliased constant Ada_Front_End.Session_Type; > > Session_Ptr : Session_Ptr_Type := Session'Access; > > It barfs here, because Session_Ptr_Type has greater scope than Session. My > problem is Close_Port needs a pointer to a Session, so I have to define the > Session_Ptr_Type at the highest level... Why does Close_Port need a pointer to a Session? If you are passing Session to C code, you should probably use 'Address rather than 'access. Or, define Close_Port to take an access parameter: function Close_Port (Session : access Session_Type); If you really, really need the interface you've given, 'unchecked_access will eliminate the error message. We need more info about what you are really doing to really help. -- Stephe ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-05 0:00 ` Stephen Leake @ 1999-01-05 0:00 ` Tom Moran 1999-01-06 0:00 ` robert_dewar 1999-01-06 0:00 ` robert_dewar 1999-01-06 0:00 ` Chris Warwick 2 siblings, 1 reply; 55+ messages in thread From: Tom Moran @ 1999-01-05 0:00 UTC (permalink / raw) >... you should probably use 'Address rather than 'access NO. 'address is non-portable. For instance, one of the compilers I use regularly uses the full Intel segment:offset form, all 32 bits, for 'address, vs 32 bits with (Win32's) implied segment for 'access. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-05 0:00 ` Tom Moran @ 1999-01-06 0:00 ` robert_dewar 1999-01-06 0:00 ` Tom Moran ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: robert_dewar @ 1999-01-06 0:00 UTC (permalink / raw) In article <36926c54.2583014@news.pacbell.net>, tmoran@bix.com (Tom Moran) wrote: > NO. 'address is non-portable. For instance, one of the > compilers I use regularly uses the full Intel > segment:offset form, all 32 bits, for 'address, vs 32 > bits with (Win32's) implied segment for 'access. First, I assume you mean full 48 bits for the segment:offset form, since that is what it is in 32-bit mode, and surely you are talking about 32-bit mode here. If so, that is an extraordinarily bad choice for a compiler to make. Why? Because there is loads of legacy code around that assumes that an Address value can be passed to C as a pointer. A compiler that does not allow this usage is in my opinion badly flawed if you want to interface to C using it. Also, what makes you think that an access type is any more portable? There is NO reason to think this. The RM provides no guarantee at all that the representation of either access types or addresses corresponds to what a C pointer looks like. Any reasonable compiler will make both access types in at least the cases that make sense to C (e.g. simple types or constrained arrays, or non-variant records), and addresses be identical to C pointers. But if what you say is true, then there are unreasonable compilers around. If so, then all bets are off regarding portability of *either* access types *or* addresses across the C boundary. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-06 0:00 ` robert_dewar @ 1999-01-06 0:00 ` Tom Moran 1999-01-07 0:00 ` robert_dewar 1999-01-06 0:00 ` Tom Moran 1999-01-06 0:00 ` Larry Kilgallen 2 siblings, 1 reply; 55+ messages in thread From: Tom Moran @ 1999-01-06 0:00 UTC (permalink / raw) >there is loads of legacy code around >that assumes that an Address value can be passed to C as >a pointer. There is loads of legacy code around that makes all sorts of unwarranted assumptions, as you yourself have noted, I believe. It may well be that this compiler, when generating code for Win32, throws away the segment part. But I've seen an awful lot of code, some of it quite new, that assumes a 'address is equivalent to a 'access. I've even gone through the pain of fixing such code to make it work on other than the original coder's compiler. And how could you possibly make an embedded 32 bit program which actually used segments as intended, with a compiler that believed there was only one segment? Clearly such a compiler would truly be broken. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-06 0:00 ` Tom Moran @ 1999-01-07 0:00 ` robert_dewar 1999-01-07 0:00 ` Tom Moran 0 siblings, 1 reply; 55+ messages in thread From: robert_dewar @ 1999-01-07 0:00 UTC (permalink / raw) In article <3693091d.42725914@news.pacbell.net>, tmoran@bix.com (Tom Moran) wrote: > And how could you possibly make an embedded 32 bit > program which actually used segments as intended, with a > compiler that believed there was only one segment? > Clearly such a compiler would truly be broken. Tom, it really sounds like you are still living in a 286 world here. All the real time executives I am familiar with in the modern ia32 world operate with a single segment model. Indeed the whole segmentation stuff in the ia32 is a bit of a relic at this stage (Henderson in reviewing my book on Microprocessors wrote a note that said "does anyone use this segment junk" or words to that effect :-) -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-07 0:00 ` robert_dewar @ 1999-01-07 0:00 ` Tom Moran 1999-01-10 0:00 ` robert_dewar 0 siblings, 1 reply; 55+ messages in thread From: Tom Moran @ 1999-01-07 0:00 UTC (permalink / raw) >"does anyone >use this segment junk" I certainly grant that it's presently out of fashion. But then a lot of ideas once out of fashion have a habit of returning as 'brilliant new innovations" later. And of course not *everyone* using an Intel cpu is running MS Windows or similar ****. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-07 0:00 ` Tom Moran @ 1999-01-10 0:00 ` robert_dewar 0 siblings, 0 replies; 55+ messages in thread From: robert_dewar @ 1999-01-10 0:00 UTC (permalink / raw) In article <369433d0.31381746@news.pacbell.net>, tmoran@bix.com (Tom Moran) wrote: > >"does anyone > >use this segment junk" > I certainly grant that it's presently out of fashion. > But then a lot of ideas once out of fashion have a habit > of returning as 'brilliant new innovations" later. And > of course not *everyone* using an Intel > cpu is running MS Windows or similar ****. Please look at the PII specs before speculating here! -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-06 0:00 ` robert_dewar 1999-01-06 0:00 ` Tom Moran @ 1999-01-06 0:00 ` Tom Moran 1999-01-07 0:00 ` robert_dewar 1999-01-06 0:00 ` Larry Kilgallen 2 siblings, 1 reply; 55+ messages in thread From: Tom Moran @ 1999-01-06 0:00 UTC (permalink / raw) >Also, what makes you think that an access type is any more >portable? Experience. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-06 0:00 ` Tom Moran @ 1999-01-07 0:00 ` robert_dewar 1999-01-07 0:00 ` Tom Moran 0 siblings, 1 reply; 55+ messages in thread From: robert_dewar @ 1999-01-07 0:00 UTC (permalink / raw) In article <369308b4.42620270@news.pacbell.net>, tmoran@bix.com (Tom Moran) wrote: > >Also, what makes you think that an access type is any more > >portable? > Experience. Yes, but I suspect this is experience with obsolete 286 based segmented architectures, I don't think it is relevant in the modern world (modern = modern architectures and operating systems and real time executives). -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-07 0:00 ` robert_dewar @ 1999-01-07 0:00 ` Tom Moran 1999-01-10 0:00 ` robert_dewar 0 siblings, 1 reply; 55+ messages in thread From: Tom Moran @ 1999-01-07 0:00 UTC (permalink / raw) >experience with obsolete 286 >based segmented architectures Oh, it goes back before that. At least to Burroughs architectures, etc. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-07 0:00 ` Tom Moran @ 1999-01-10 0:00 ` robert_dewar 1999-01-10 0:00 ` Tom Moran 0 siblings, 1 reply; 55+ messages in thread From: robert_dewar @ 1999-01-10 0:00 UTC (permalink / raw) In article <36943353.31256483@news.pacbell.net>, tmoran@bix.com (Tom Moran) wrote: > >experience with obsolete 286 > >based segmented architectures > Oh, it goes back before that. At least to Burroughs architectures, > etc. That's intriguing, the particular issue here is specific to Ada (how is 'Address repreesented?) what Ada compiler did you have for Burroughs machines? -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-10 0:00 ` robert_dewar @ 1999-01-10 0:00 ` Tom Moran 1999-01-10 0:00 ` robert_dewar 1999-01-10 0:00 ` robert_dewar 0 siblings, 2 replies; 55+ messages in thread From: Tom Moran @ 1999-01-10 0:00 UTC (permalink / raw) > tmoran@bix.com (Tom Moran) wrote: >> >experience with obsolete 286 >> >based segmented architectures >> Oh, it goes back before that. At least to Burroughs >architectures, >> etc. >That's intriguing, the particular issue here is specific >to Ada (how is 'Address repreesented?) what Ada compiler >did you have for Burroughs machines? Sorry, I was trying to correct your apparent impression that segmented architectures started with the 286. The closest to an Ada compiler I ever had for a Burroughs machine was a simple little toy one I wrote in the early 80's on a B6700, but the B5500 of course had segments over 15 years earlier. See the book by Elliot Organick for more info. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-10 0:00 ` Tom Moran @ 1999-01-10 0:00 ` robert_dewar 1999-01-10 0:00 ` robert_dewar 1 sibling, 0 replies; 55+ messages in thread From: robert_dewar @ 1999-01-10 0:00 UTC (permalink / raw) In article <369850a6.31871728@news.pacbell.net>, tmoran@bix.com (Tom Moran) wrote: > Sorry, I was trying to correct your apparent impression > that segmented architectures started with the 286. The > closest to an Ada compiler I ever had for a Burroughs > machine was a simple little toy one I wrote in the early > 80's on a B6700, but the B5500 of course had segments > over 15 years earlier. See the book by Elliot Organick > for more info. A couple of postscripts here First of all, you surely mean the 8086 rather than the 286 in the above. The segmentation model for the x86 architectures was present in the 8086, and the 286 protected model is simply an adaptation of this original segmentation model. Second, the whole point is that the 8086 segmentation did NOT derive from the historical thread exemplified by the Burroughs architecture. I would not be surprised if Steve was unaware of this architecture (I will ask him next time I talk to him). It came out of completely different requirements, and really it is only the word "segmentation" that the 8086 and the B5500 have in common, especially with regard to the 8086. You could if you did not know better regard the 80386 model as coming from the B5500 thread of thought, but you would be wrong, any similarity is purely accidental, since the 80386 derived directly from the 80286 which came from the 8086, each step being the result of asking "how can we address more memory?" [1 meg on 8086, 16 megs on 80286, 4 gigs on 386] Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-10 0:00 ` Tom Moran 1999-01-10 0:00 ` robert_dewar @ 1999-01-10 0:00 ` robert_dewar 1999-01-10 0:00 ` Pat Rogers 1999-01-10 0:00 ` Tom Moran 1 sibling, 2 replies; 55+ messages in thread From: robert_dewar @ 1999-01-10 0:00 UTC (permalink / raw) In article <369850a6.31871728@news.pacbell.net>, tmoran@bix.com (Tom Moran) wrote: > Sorry, I was trying to correct your apparent impression > that segmented architectures started with the 286. The > closest to an Ada compiler I ever had for a Burroughs > machine was a simple little toy one I wrote in the early > 80's on a B6700, but the B5500 of course had segments > over 15 years earlier. See the book by Elliot Organick > for more info. Tom, just so you know, I am a reasonable expert on processor architecture, and have of course worked with the B5500 (I wrote some large applications for this machine for the banking industry). Yes, of course, the 8086 did not invent segmentation per se, but assuming *you* know the 5500 architecture well (most people do not, seeing as it was only programmed in high level languages, and there was no assembler), then you will know that the model of segmentation in the 5500 is completely different from that of the 8086. The real point here though is that the thread was about the representation of System.Address and access types in Ada. Your comments about segmentation in this context were, I assumed, and I think correctly, related specifically to the 80286, and are therefore probably irrelevant at this stage. Yes, segmentation is present in the PII, for compatibility purposes, and used in some limited manners in the operating system kernel, but it would be *very* surprising to find an Ada compiler that used 48-bit representations for addresses. Even if you did want your Ada compiler to handle segmentation, this is not the way you would do it! So my original point is valid, and should not be obfuscated by concerns about segmentation on the 286! Namely that the representation of both Address and access types to simple C-compatible objects will in practice be the same as C pointers in virtually all implementations. Remember after all that in C itself, there is no guarantee that a pointer value looks like a machine pointer. Indeed from a semantic point of view in C, a pointer is a two element structure, consisting of a base address in an allocated object and an offset. One can imagine a checking compiler (or a C-specific architecture) that represents pointers that way, but it is very unlikely. It is in fact interesting to note that C does NOT provide a linear view of the address space, so general address arithmetic is not possible in C. Yes, your C compiler may provide such a capability in practice but you are using undefined operations. In contrast, Ada 95 *does* provide a linear address model via the Integer_Address type in System.Storage_Elements. You can for example in Ada, but not in C, create fully conforming portable code that provides hashing of addresses of objects, this is not possible in strict C. For more details on the segmentation mechanism in the x86, and in particular the interesting history of how it came about, read chapters 2-3 in my Microprocessors book (Microprocessors: A Programmer's View, McGraw Hill 1990). Interestingly, although this book is quite old now, most of it is still quite up to date. It is really only the EPIC introduction that will make it out of date :-) Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-10 0:00 ` robert_dewar @ 1999-01-10 0:00 ` Pat Rogers 1999-01-10 0:00 ` Tom Moran 1 sibling, 0 replies; 55+ messages in thread From: Pat Rogers @ 1999-01-10 0:00 UTC (permalink / raw) robert_dewar@my-dejanews.com wrote in message <77abdp$d5e$1@nnrp1.dejanews.com>... <snip> >For more details on the segmentation mechanism in the x86, >and in particular the interesting history of how it came >about, read chapters 2-3 in my Microprocessors book >(Microprocessors: A Programmer's View, McGraw Hill 1990). >Interestingly, although this book is quite old now, most >of it is still quite up to date. It is really only the EPIC >introduction that will make it out of date :-) Recommended reading, still. You'll be pleased to hear, I'm sure, that the Intel chapter has been read extensively by some of the individuals involved with the emulator for the Space Station on-board processor (for the Station training simulator). ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-10 0:00 ` robert_dewar 1999-01-10 0:00 ` Pat Rogers @ 1999-01-10 0:00 ` Tom Moran 1 sibling, 0 replies; 55+ messages in thread From: Tom Moran @ 1999-01-10 0:00 UTC (permalink / raw) >segmentation is present in the PII, for >compatibility purposes, and used in some limited manners in >the operating system kernel How could one write such operating system kernel code with a compiler that did not recognize the existence of segmented addresses? (Other than using asm code.) > Ada 95 *does* provide >a linear address model via the Integer_Address type in >System.Storage_Elements Besides the use of segments in the 8086 as a way of partially caching memory address, and its additional use in the 286/B5500 et al for protection and virtual memory, what about things like bank memory architectures (eg, CDC160-A/8090 to name one)? What does System.Storage_Elements."-" do when the two addresses are in different distributied partitions, potentially on different machines? Raise Program_Error, depending on where the partitions happen to reside? I hope not. >C does NOT provide a >linear view of the address space, so general address >arithmetic is not possible in C I sure wish I had a penny for each C programmer who believes that in char a[10],b; 'b' is the same as a[10]. And of course the 'buffer overflow' security holes demonstrate that is usually a correct assumption. >assuming *you* know the 5500 architecture well A long time ago, as an RA in the U of Wisconsin Computer Center, most of my job was maintaining and enhancing the OS on their B5500s. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-06 0:00 ` robert_dewar 1999-01-06 0:00 ` Tom Moran 1999-01-06 0:00 ` Tom Moran @ 1999-01-06 0:00 ` Larry Kilgallen 1999-01-06 0:00 ` Tom Moran 2 siblings, 1 reply; 55+ messages in thread From: Larry Kilgallen @ 1999-01-06 0:00 UTC (permalink / raw) In article <76uvjt$o0f$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com writes: > In article <36926c54.2583014@news.pacbell.net>, > tmoran@bix.com (Tom Moran) wrote: >> NO. 'address is non-portable. For instance, one of the >> compilers I use regularly uses the full Intel >> segment:offset form, all 32 bits, for 'address, vs 32 >> bits with (Win32's) implied segment for 'access. > > First, I assume you mean full 48 bits for the > segment:offset form, since that is what it is in 32-bit > mode, and surely you are talking about 32-bit mode here. > > If so, that is an extraordinarily bad choice for a compiler > to make. Why? Because there is loads of legacy code around > that assumes that an Address value can be passed to C as > a pointer. A compiler that does not allow this usage is in > my opinion badly flawed if you want to interface to C using > it. For the sake of portability, a compiler should at least flag all such usages that are not guaranteed to work by the standard against which it is written. Not working on the development platform is a very large hammer, but perhaps it is justified for Ada 95 where there is a supported mechanism for calling to some of the other standardized languages. Also, representation of addresses can vary even on a single platform, so sometimes you have to know how the other language code (or portion thereof) was compiled to know how big _it_ thinks an address is. It would not do to have the C code stuff a 64 bit address into your 32 bit address variable. Larry Kilgallen ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-06 0:00 ` Larry Kilgallen @ 1999-01-06 0:00 ` Tom Moran 0 siblings, 0 replies; 55+ messages in thread From: Tom Moran @ 1999-01-06 0:00 UTC (permalink / raw) Perhaps one should think of 'address as a hardware-level concept, and 'access as software-level. Then stay at the software level unless you actually need to deal with the hardware level. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-05 0:00 ` Stephen Leake 1999-01-05 0:00 ` Tom Moran @ 1999-01-06 0:00 ` robert_dewar 1999-01-06 0:00 ` Chris Warwick 2 siblings, 0 replies; 55+ messages in thread From: robert_dewar @ 1999-01-06 0:00 UTC (permalink / raw) In article <uiuelbj6r.fsf@gsfc.nasa.gov>, Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote: > Why does Close_Port need a pointer to a Session? If you > are passing Session to C code, you should probably use > 'Address rather than 'access. Or, define Close_Port to > take an access parameter: I consider both of these pieces of advice wrong. It is Ada 83 thinking to go to untyped addresses for this purpose. Pointers in Ada *and* C are typed, and passing untyped pointers across the interface represents unnecessary weakening of the typing system. It is far better to use Access (or Unchecked_Access which is still far safer than Address). As for using an access parameter, there is a very big trap here that people keep falling into. An access parameter may NOT be null, and typical C interfaces can accept null values. Also, using an access parameter does not obviate the need for using 'Access, though of course it makes it easier to use it. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-05 0:00 ` Stephen Leake 1999-01-05 0:00 ` Tom Moran 1999-01-06 0:00 ` robert_dewar @ 1999-01-06 0:00 ` Chris Warwick 1999-01-06 0:00 ` Tom Moran ` (2 more replies) 2 siblings, 3 replies; 55+ messages in thread From: Chris Warwick @ 1999-01-06 0:00 UTC (permalink / raw) Stephen Leake wrote in message ... >Why does Close_Port need a pointer to a Session? If you are passing >Session to C code, you should probably use 'Address rather than >'access. Or, define Close_Port to take an access parameter: I am indeed passing this to some C code, and I realize that what I am doing is cheating, just a little. The reason is I can't seem to get the stuff to the C function by value, if I pass it by reference its happy, but it barfs when I try to do it by value. My old trick of translating pointers into Ada types by creating a function to return the record by value also doesn't work... >function Close_Port (Session : access Session_Type); > >If you really, really need the interface you've given, >'unchecked_access will eliminate the error message. Thanks, it does indeed eliminate the error, but it leaves me with a bad taste. Somewhat like resorting to an unchecked_conversion. Is there a "proper" way to do this, or am I stuck with the unchecked solution? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-06 0:00 ` Chris Warwick @ 1999-01-06 0:00 ` Tom Moran 1999-01-07 0:00 ` robert_dewar 1999-01-07 0:00 ` Stephen Leake 2 siblings, 0 replies; 55+ messages in thread From: Tom Moran @ 1999-01-06 0:00 UTC (permalink / raw) >>'unchecked_access will eliminate the error message. >Thanks, it does indeed eliminate the error, but it leaves me with a bad >taste. Somewhat like resorting to an unchecked_conversion. I used to feel that way too, but now realize that in fact it is merely an explicit indication that I'm trusting the called C function to not hang onto the pointer after the thing it pointed to is gone. ie, the nervousness is due to calling such C functions, not to using 'unchecked_conversion. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-06 0:00 ` Chris Warwick 1999-01-06 0:00 ` Tom Moran @ 1999-01-07 0:00 ` robert_dewar 1999-01-09 0:00 ` Chris Warwick 1999-01-07 0:00 ` Stephen Leake 2 siblings, 1 reply; 55+ messages in thread From: robert_dewar @ 1999-01-07 0:00 UTC (permalink / raw) In article <770ifd$qui$1@goblin.uunet.ca>, "Chris Warwick" <chris.warwick@cdcgy.com> wrote: > Is there a "proper" way to do this, or am I stuck with > the unchecked solution? You can't have it both ways, If you insist on structuring your program in a manner that leaves it open to the possibilities of dangling pointers, then you have to use Unchecked_Access. Proper restructuring can often, but not always, remove the need for this. Note that Unchecked_Access is of course no more dangerous from the point of view of accessibility violations than 'Address. Does 'Address make you equally uneasy? If not you are being over concerned at names, when functionality is more significant! -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-07 0:00 ` robert_dewar @ 1999-01-09 0:00 ` Chris Warwick 1999-01-09 0:00 ` Simon Wright 1999-01-09 0:00 ` Brian Rogoff 0 siblings, 2 replies; 55+ messages in thread From: Chris Warwick @ 1999-01-09 0:00 UTC (permalink / raw) In article <771bl9$sla$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com wrote: >You can't have it both ways, If you insist on structuring >your program in a manner that leaves it open to the >possibilities of dangling pointers, then you have to use >Unchecked_Access. I guess this where I get confused. If I want to pass a pointer amoungst these functions/procedures I have to define the type at the package level. As a result there is no way for someone to define an instance of the pointer at a lower level, i.e., as a local variable within a procedure. Another way to get this to function would be to define as instance of the pointer as a global variable for the package, but then I have to mutex it to prevent different tasks from getting messed up (which seems unnecessarily awkward). I think I understand the rules, but I am confused as to how this "should" work. >Proper restructuring can often, but not >always, remove the need for this. Note that >Unchecked_Access is of course no more dangerous from the >point of view of accessibility violations than 'Address. >Does 'Address make you equally uneasy? If not you are being >over concerned at names, when functionality is more >significant! I've got it working... My uneasyness stems from the fact that when I ran into unchecked_conversion I was able to get someone to explain to me how it really was "supposed" to work, and once I understood, I agreed. Thus far I still do not understand how a package can export a "useful" pointer definition... ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-09 0:00 ` Chris Warwick @ 1999-01-09 0:00 ` Simon Wright 1999-01-10 0:00 ` robert_dewar 1999-01-09 0:00 ` Brian Rogoff 1 sibling, 1 reply; 55+ messages in thread From: Simon Wright @ 1999-01-09 0:00 UTC (permalink / raw) warwicks@telusplanet.net (Chris Warwick) writes: > I've got it working... My uneasyness stems from the fact that when I > ran into unchecked_conversion I was able to get someone to explain > to me how it really was "supposed" to work, and once I understood, I > agreed. Thus far I still do not understand how a package can export > a "useful" pointer definition... There's no trouble if you allocate on the heap (using new). You can also create aliased variables at package level. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-09 0:00 ` Simon Wright @ 1999-01-10 0:00 ` robert_dewar 1999-01-11 0:00 ` Simon Wright 1999-01-16 0:00 ` Chris Warwick 0 siblings, 2 replies; 55+ messages in thread From: robert_dewar @ 1999-01-10 0:00 UTC (permalink / raw) In article <x7vpv8pkjtt.fsf@pogner.demon.co.uk>, warwicks@telusplanet.net (Chris Warwick) writes: > I've got it working... My uneasyness stems from the >fact > that when I ran into unchecked_conversion I was able to > get someone to explain to me how it really was "supposed" > to work, and once I understood, I agreed. Thus far I > still do not understand how a package can export > a "useful" pointer definition... But this problem only arises for the unusual case of aliased variables, which normally should be used only for interfacing to foreign routines, where the use of unchecked_access is entirely appropriate. I notice that a lot of people, especially former C programmers greatly overuse aliased variables. There was a reason for completely excluding such variables from the Ada 83 language, and good practice in Ada 95 is to absolutely minimize their use. Certainly the idea that a package is not useful because it requires the use of Unchecked_Access for the unusual case of using aliased variables represents an entirely inappropriate viewpoint for the Ada 95 world. Remember that aliased variables were introduced for limited purposes in Ada 95, if you find yourself making everything aliased, you are probably not organizing things in an appropriate manner. For example, even in the case of calls to interfaced routines, we far prefer to pass IN or IN OUT parameters by reference than to pass pointers as a general rule. Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-10 0:00 ` robert_dewar @ 1999-01-11 0:00 ` Simon Wright 1999-01-16 0:00 ` Chris Warwick 1 sibling, 0 replies; 55+ messages in thread From: Simon Wright @ 1999-01-11 0:00 UTC (permalink / raw) robert_dewar@my-dejanews.com writes: > For example, even in the case of calls to interfaced > routines, we far prefer to pass IN or IN OUT parameters > by reference than to pass pointers as a general rule. This remark led me to re-read RM B.3(63) and following; thanks! ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-10 0:00 ` robert_dewar 1999-01-11 0:00 ` Simon Wright @ 1999-01-16 0:00 ` Chris Warwick 1999-01-16 0:00 ` Matthew Heaney ` (2 more replies) 1 sibling, 3 replies; 55+ messages in thread From: Chris Warwick @ 1999-01-16 0:00 UTC (permalink / raw) In article <77b9cp$5kh$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com wrote: >I notice that a lot of people, especially former C >programmers greatly overuse aliased variables. There >was a reason for completely excluding such variables >from the Ada 83 language, and good practice in Ada 95 >is to absolutely minimize their use. >Remember that aliased variables were introduced for >limited purposes in Ada 95, if you find yourself making >everything aliased, you are probably not organizing >things in an appropriate manner. This thread has wandered off into the theory behind Ada, for that I apologize, and thank everyone for their patience... I will admit some guilt at being a "reformed" C programmer... But, what I find odd is the concept that pointing to an object on the "stack" is poor practice. Even from my Ada83 days, the only "safe" way to do dynamic memory allocation was though the use of local variables on the stack. If I understand this concept, then the view is that it is better to point to a newly allocated buffer, then it is to point to a procedure's local variable. Given that most Ada compilers have no way to deallocate memory, I seem to be trading the potential for a pointer to exist past the life of the allocated memory for a program continously allocates memory... ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-16 0:00 ` Chris Warwick @ 1999-01-16 0:00 ` Matthew Heaney 1999-01-16 0:00 ` robert_dewar 1999-01-18 0:00 ` Chris Warwick 1999-01-16 0:00 ` robert_dewar 1999-01-16 0:00 ` Simon Wright 2 siblings, 2 replies; 55+ messages in thread From: Matthew Heaney @ 1999-01-16 0:00 UTC (permalink / raw) warwicks@telusplanet.net (Chris Warwick) writes: > I will admit some guilt at being a "reformed" C programmer... But, what I find > odd is the concept that pointing to an object on the "stack" is poor practice. Maybe what Robert is saying is that, given a choice between 1) declaring an object (on the stack) as aliased, taking the 'Access of that aliased object, and passing that access value to an external subprogram; or 2) declaring an object (on the stack), without declaring it as aliased, and passing that object directly, as an in out parameter passed by reference; that 2) is that preferred alternative. > Even from my Ada83 days, the only "safe" way to do dynamic memory > allocation was though the use of local variables on the stack. If I > understand this concept, then the view is that it is better to point > to a newly allocated buffer, then it is to point to a procedure's > local variable. I think this was the thinking by the Ada83 designers. They were trying desperately to avoid the possibility of dangling references. I didn't especially like this "feature" of Ada83. I think a language should make it difficult for me to do something potentially error-prone (like take the address of a stack object), but not impossible. The language should get the hell out of my way. > Given that most Ada compilers have no way to deallocate memory, I seem > to be trading the potential for a pointer to exist past the life of > the allocated memory for a program continously allocates memory... I don't think anyone is advocating that you create memory leaks. Although officially all Unchecked_Conversion has to do is set the pointer passed in to null, without actually deallocating any memory, in practice UC really does reclaim memory. It's just like free(). So it is untrue that "most Ada compilers have no way to deallocate memory." (Because the terms "heap" and "deallocate memory" aren't formally specifiable, there's nothing the RM can do except specify external behavior, as in "set the pointer to null.") The moral of the story is that, in general, when you have a choice, don't manipulate references ("pointers") directly. The language mandates the argument passing mechanism (by val vs by ref) for types passed to a subprogram having a C convention, so the idea is to let the compiler generate the reference ("address") automatically. Now if we could only declare in out args for "value-returning subprograms"... -- Those who believe in the supernatural should be required to learn computer programming. This would force them to discover that things which appear at first to be completely mysterious and incomprehensible, in fact have a logical (and usually simple) explanation. --J.B.R. Yant ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-16 0:00 ` Matthew Heaney @ 1999-01-16 0:00 ` robert_dewar 1999-01-18 0:00 ` Chris Warwick 1 sibling, 0 replies; 55+ messages in thread From: robert_dewar @ 1999-01-16 0:00 UTC (permalink / raw) In article <m3btjzipgf.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > Now if we could only declare in out args for > "value-returning subprograms"... Note that in GNAT and DEC Ada, this is indeed possible, using the Import/Export_Valued_Procedure pragmas. But let's not start this weary thread again :-) :-) -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-16 0:00 ` Matthew Heaney 1999-01-16 0:00 ` robert_dewar @ 1999-01-18 0:00 ` Chris Warwick 1999-01-18 0:00 ` Matthew Heaney ` (2 more replies) 1 sibling, 3 replies; 55+ messages in thread From: Chris Warwick @ 1999-01-18 0:00 UTC (permalink / raw) In article <m3btjzipgf.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: >Although officially all Unchecked_Conversion has to do is set the >pointer passed in to null, without actually deallocating any memory, in >practice UC really does reclaim memory. It's just like free(). So it >is untrue that "most Ada compilers have no way to deallocate memory." Of all the Ada compilers I have dealt with, both 83 and 95, none deallocate memory to my knowledge (GNAT may, but I haven't had need to look). Indeed this is one of the first questions I ask when I discover c++ programmers using Ada... >(Because the terms "heap" and "deallocate memory" aren't formally >specifiable, there's nothing the RM can do except specify external >behavior, as in "set the pointer to null.") At the last Tri-Ada I went to there was a discussion on how to fix this (95 allows you to define individual allocation strategies), but the gent who was trying had given up as it was too difficult... >The moral of the story is that, in general, when you have a choice, >don't manipulate references ("pointers") directly. The language >mandates the argument passing mechanism (by val vs by ref) for types >passed to a subprogram having a C convention, so the idea is to let the >compiler generate the reference ("address") automatically. I agree with this, but I am finding it difficult to use the Object features of Ada 95 without using pointers. This situation can up, because the compiler I am using refuses to pass anything by value, and I am stuck with pointers passed through the interface code. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-18 0:00 ` Chris Warwick @ 1999-01-18 0:00 ` Matthew Heaney 1999-01-18 0:00 ` robert_dewar 1999-01-18 0:00 ` dennison 2 siblings, 0 replies; 55+ messages in thread From: Matthew Heaney @ 1999-01-18 0:00 UTC (permalink / raw) warwicks@telusplanet.net (Chris Warwick) writes: > In article <m3btjzipgf.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > > >Although officially all Unchecked_Conversion has to do is set the > >pointer passed in to null, without actually deallocating any memory, in > >practice UC really does reclaim memory. It's just like free(). So it > >is untrue that "most Ada compilers have no way to deallocate memory." > > Of all the Ada compilers I have dealt with, both 83 and 95, none > deallocate memory to my knowledge (GNAT may, but I haven't had need to > look). Indeed this is one of the first questions I ask when I discover > c++ programmers using Ada... I don't know what you mean here. Are you saying that the compilers don't come with a garbage collector, or are you saying that when you (manually) called an instantiation of unchecked_deallocation, the memory didn't get deallocated? Except for recent compilers that target the Java VM, no known Ada compilers come with a garbage collector. All known Ada compilers really do deallocate memory when you call Unchecked_Deallocation. Please state whether you are refering to a manual invokation of Unchecked_Deallocation, or to an automatic gargage collector; and, state which specific compilers from which specific vendors you were using. Perhaps this is a just a misunderstanding about what "deallocating memory" means. > >(Because the terms "heap" and "deallocate memory" aren't formally > >specifiable, there's nothing the RM can do except specify external > >behavior, as in "set the pointer to null.") > > At the last Tri-Ada I went to there was a discussion on how to fix > this (95 allows you to define individual allocation strategies), but > the gent who was trying had given up as it was too difficult... State the exact paper that was presented, and the email address of the presenter. I will speak to him to see if we can sort out his difficulties. > >The moral of the story is that, in general, when you have a choice, > >don't manipulate references ("pointers") directly. The language > >mandates the argument passing mechanism (by val vs by ref) for types > >passed to a subprogram having a C convention, so the idea is to let the > >compiler generate the reference ("address") automatically. > > I agree with this, but I am finding it difficult to use the Object > features of Ada 95 without using pointers. This situation came up, > because the compiler I am using refuses to pass anything by value, and > I am stuck with pointers passed through the interface code. What convention are you using? The language states what the passing mechanism is for various types for language-defined conventions. Perhaps if you post a small example of code that "refuses to pass anything by value," we can analyze it to see if we can figure out what the problem is. -- Those who believe in the supernatural should be required to learn computer programming. This would force them to discover that things which appear at first to be completely mysterious and incomprehensible, in fact have a logical (and usually simple) explanation. --J.B.R. Yant ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-18 0:00 ` Chris Warwick 1999-01-18 0:00 ` Matthew Heaney @ 1999-01-18 0:00 ` robert_dewar 1999-01-18 0:00 ` Tucker Taft 1999-01-18 0:00 ` dennison 1999-01-18 0:00 ` dennison 2 siblings, 2 replies; 55+ messages in thread From: robert_dewar @ 1999-01-18 0:00 UTC (permalink / raw) In article <sYyo2.8309$Kg6.62453@news2.telusplanet.net>, warwicks@telusplanet.net (Chris Warwick) wrote: > In article <m3btjzipgf.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > Of all the Ada compilers I have dealt with, both 83 and > 95, none deallocate memory to my knowledge (GNAT may, but > I haven't had need to look). Indeed this is one of the > first questions I ask when I discover c++ programmers > using Ada... You need to cite chapter and verse here. I have worked with many many Ada compilers, and none of them ignored unchecked deallocation, and it is hard to imagine that any would. Of course GNAT deallocates memory, but I would never claim this is a special advantage of GNAT, since all Ada compilers deallocate memory. The only instance I know of in commercial Ada compilers which might give rise to such a peculiar claim is the old obsolete Alsys 386 compiler, which for local collections (not very common in practice) delayed the deallocation till scope exit, but even there to say that the memory was not deallocated is false. Just what *are* you talking about here. I have often heard misinformation about Ada spread, but this is among the most extraordinary examples! -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-18 0:00 ` robert_dewar @ 1999-01-18 0:00 ` Tucker Taft 1999-01-19 0:00 ` Chris Warwick 1999-01-18 0:00 ` dennison 1 sibling, 1 reply; 55+ messages in thread From: Tucker Taft @ 1999-01-18 0:00 UTC (permalink / raw) robert_dewar@my-dejanews.com wrote: : In article <sYyo2.8309$Kg6.62453@news2.telusplanet.net>, : warwicks@telusplanet.net (Chris Warwick) wrote: : > Of all the Ada compilers I have dealt with, both 83 and : > 95, none deallocate memory to my knowledge (GNAT may, but : > I haven't had need to look). Indeed this is one of the : > first questions I ask when I discover c++ programmers : > using Ada... : You need to cite chapter and verse here. I have worked with : many many Ada compilers, and none of them ignored unchecked : deallocation, and it is hard to imagine that any would. : Of course GNAT deallocates memory, but I would never claim : this is a special advantage of GNAT, since all Ada : compilers deallocate memory. : The only instance I know of in commercial Ada compilers : which might give rise to such a peculiar claim is the : old obsolete Alsys 386 compiler, which for local : collections (not very common in practice) delayed the : deallocation till scope exit, but even there to say that : the memory was not deallocated is false. : Just what *are* you talking about here. I have often heard : misinformation about Ada spread, but this is among the : most extraordinary examples! I can imagine that perhaps Chris Warwick meant that Unchecked_Deallocation recycles storage for use by later allocators, but never returns it to the operating system. This does not surprise me, because the total memory required by a program, even with perfect reclamation, rarely goes down over time, so giving memory back to the operating system temporarily seems like an expensive thing to do for little potential payoff. Chris, is that what you meant? If so, I am curious what sort of application system requires this behavior. For what it is worth, there are a number of Ada 95 compilers (e.g. on VxWorks and Windows NT) which directly connect to the underlying operating system malloc/free when the user uses allocators/unchecked-deallocation. I suppose these "operating system" malloc/frees might recycle storage to other concurrently running processes, though I don't know for sure. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-18 0:00 ` Tucker Taft @ 1999-01-19 0:00 ` Chris Warwick 1999-01-19 0:00 ` Stephen Leake ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: Chris Warwick @ 1999-01-19 0:00 UTC (permalink / raw) In article <F5rJF8.8sB.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) wrote: >I can imagine that perhaps Chris Warwick meant that >Unchecked_Deallocation recycles storage for use by later >allocators, but never returns it to the operating system. >This does not surprise me, because the total memory required >by a program, even with perfect reclamation, rarely >goes down over time, so giving memory back to the operating >system temporarily seems like an expensive thing to do for >little potential payoff. > >Chris, is that what you meant? If so, I am curious >what sort of application system requires this behavior. I don't want to turn this into a vendor bash... Of the Ada compilers I have used, the unchecked_deallocation on all of them was to set the pointer to 0 and carry on (i.e., no calls to deallocate, no storing the un-used memory for later re-allocation by the Ada program). When I first stumbled into this I was told that this was for safety reasons. It may have been that I have been using safety critical versions of these Ada compilers, and "standard" compilers are different... I am certainly willing to change my outlook as I get more data, but as long as I keep asking vendors, and keep getting told that my belief is correct, then I am reluctant to change my view... BTW: my last attempt to raise this question was last September, and was for their Ada 95 product... ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-19 0:00 ` Chris Warwick @ 1999-01-19 0:00 ` Stephen Leake 1999-01-19 0:00 ` robert_dewar 1999-01-19 0:00 ` Tom Moran 2 siblings, 0 replies; 55+ messages in thread From: Stephen Leake @ 1999-01-19 0:00 UTC (permalink / raw) warwicks@telusplanet.net (Chris Warwick) writes: > I don't want to turn this into a vendor bash... This is comp.lang.ada, and the behavior of Unchecked_Deallocation is important; it is perfectly appropriate to name names here! Otherwise, you are indulging in Ada bashing, a far worse crime :). -- Stephe ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-19 0:00 ` Chris Warwick 1999-01-19 0:00 ` Stephen Leake @ 1999-01-19 0:00 ` robert_dewar 1999-01-20 0:00 ` Jeff Carter 1999-01-19 0:00 ` Tom Moran 2 siblings, 1 reply; 55+ messages in thread From: robert_dewar @ 1999-01-19 0:00 UTC (permalink / raw) In article <naRo2.8635$Kg6.64266@news2.telusplanet.net>, warwicks@telusplanet.net (Chris Warwick) wrote: > Of the Ada compilers I have used, the > unchecked_deallocation on all of them > was to set the pointer to 0 and carry on (i.e., no calls > to deallocate, no > storing the un-used memory for later re-allocation by the > Ada program). When I > first stumbled into this I was told that this was for > safety reasons. It may > have been that I have been using safety critical versions > of these Ada > compilers, and "standard" compilers are different... > I have already discussed this with Chris. He claimed that VADS behaved as above, which I know to be incorrect, and he claimed that Alsys behaved as above. I particularly know the latter claim to be false, since I wrote that code! The one thing in Alsys that he may be referring to was that for certain cases of small blocks in local collections, we deferred collecting the storage till scope exit, but that is the only case where there was even a deferral of the free operation. The claim that this has to do with safety is just wrong. And as for safety critical subsets, clearly these do not even allow Unchecked_Deallocation in the first place. Clearly Chris's statements here are based on misinformation, or misinterpretation of some kind, and it is important not to be mislead by them. Unchecked_Deallocation works just fine on all Ada compilers and always has, it is as reliable as free in C (and indeed on many compilers translates directly into a free call). -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-19 0:00 ` robert_dewar @ 1999-01-20 0:00 ` Jeff Carter 1999-01-20 0:00 ` robert_dewar 0 siblings, 1 reply; 55+ messages in thread From: Jeff Carter @ 1999-01-20 0:00 UTC (permalink / raw) robert_dewar@my-dejanews.com wrote: > > In article <naRo2.8635$Kg6.64266@news2.telusplanet.net>, > warwicks@telusplanet.net (Chris Warwick) wrote: > > > Of the Ada compilers I have used, the > > unchecked_deallocation on all of them > > was to set the pointer to 0 and carry on (i.e., no calls > > to deallocate, no > > storing the un-used memory for later re-allocation by the > > Ada program). When I > > first stumbled into this I was told that this was for > > safety reasons. It may > > have been that I have been using safety critical versions > > of these Ada > > compilers, and "standard" compilers are different... > > > > I have already discussed this with Chris. He claimed that > VADS behaved as above, which I know to be incorrect, and > he claimed that Alsys behaved as above. I particularly know > the latter claim to be false, since I wrote that code! The > one thing in Alsys that he may be referring to was that for > certain cases of small blocks in local collections, we > deferred collecting the storage till scope exit, but that > is the only case where there was even a deferral of the > free operation. > > The claim that this has to do with safety is just wrong. > > And as for safety critical subsets, clearly these do not > even allow Unchecked_Deallocation in the first place. > > Clearly Chris's statements here are based on > misinformation, or misinterpretation of some kind, > and it is important not to be mislead by them. > > Unchecked_Deallocation works just fine on all Ada compilers > and always has, it is as reliable as free in C (and indeed > on many compilers translates directly into a free call). > FWIW, the first Ada compiler I used was the Rolm compiler for the Data General Eclipse in 1984, which claimed to be the first validated Ada-83 compiler. This machine allocated an unheard-of (in 1984) 4 GB of virtual memory for every process. I was told that this compiler's Unchecked_Deallocation only set the access variable to null without reusing the allocated memory, because no one could ever use up 4 GB. This compiler was used only for training and I never verified this statement. This is the only compiler I have used in the last 15 years that did not deallocate memory. However, I was also told that this compiler was the reason Booch included memory-managed components in his components. There seems to be a lot of hearsay in this post ... -- Jeff Carter E-mail: carter commercial-at innocon [period | full stop] com "We burst our pimples at you." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-20 0:00 ` Jeff Carter @ 1999-01-20 0:00 ` robert_dewar 1999-01-21 0:00 ` Chris Warwick 0 siblings, 1 reply; 55+ messages in thread From: robert_dewar @ 1999-01-20 0:00 UTC (permalink / raw) In article <36A5DB4E.CC5C88A@spam.innocon.com>, Jeff Carter <spam.carter.not@spam.innocon.com> wrote: > FWIW, the first Ada compiler I used was the Rolm compiler > for the Data General Eclipse in 1984, which claimed to be > the first validated Ada-83 compiler. This machine > allocated an unheard-of (in 1984) 4 GB of virtual > memory for every process. I was told that this compiler's > Unchecked_Deallocation only set the access variable to > null without reusing the allocated memory, because no one > could ever use up 4 GB. This compiler was used only for > training and I never verified this statement. A couple of comments. That was indeed a VERY early Ada compiler (not quite the first, NYU Ada/Ed was validated before the Rolm compiler, they had certificate number 0002). Well perhaps their publicity department is clearer than I am on the difference between a compiler and an interpretor :-) It is quite believable that this very early version of the Rolm compiler behaved in the way you mention, but to extrapolate from that to actual production compilers in use from the 80's is pretty bogus, so I agree, a lot of heresay here :-) -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-20 0:00 ` robert_dewar @ 1999-01-21 0:00 ` Chris Warwick 0 siblings, 0 replies; 55+ messages in thread From: Chris Warwick @ 1999-01-21 0:00 UTC (permalink / raw) In article <7853rt$ic5$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com wrote: >... so I agree, a lot of >heresay here :-) and, for that I apologize... my opinions are based on my experience, and from my interactions with compiler support organizations.. and as such are imperfect. In any case, a quick generic at the application layer to handle a free-list of deallocated memory solves the problem... Perhaps I should re-post the problem, and see if we can re-focus the discussion... ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-19 0:00 ` Chris Warwick 1999-01-19 0:00 ` Stephen Leake 1999-01-19 0:00 ` robert_dewar @ 1999-01-19 0:00 ` Tom Moran 2 siblings, 0 replies; 55+ messages in thread From: Tom Moran @ 1999-01-19 0:00 UTC (permalink / raw) >I don't want to turn this into a vendor bash... >Of the Ada compilers I have used, It would be shorter to have you list all these compilers that don't deallocate, than to have each vendor wander by here and post a note that their compiler does deallocate. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-18 0:00 ` robert_dewar 1999-01-18 0:00 ` Tucker Taft @ 1999-01-18 0:00 ` dennison 1 sibling, 0 replies; 55+ messages in thread From: dennison @ 1999-01-18 0:00 UTC (permalink / raw) In article <77vi4q$o7l$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com wrote: > In article <sYyo2.8309$Kg6.62453@news2.telusplanet.net>, > warwicks@telusplanet.net (Chris Warwick) wrote: > > In article <m3btjzipgf.fsf@mheaney.ni.net>, Matthew > Heaney <matthew_heaney@acm.org> wrote: > > > Of all the Ada compilers I have dealt with, both 83 and > > 95, none deallocate memory to my knowledge (GNAT may, but > > I haven't had need to look). Indeed this is one of the > > first questions I ask when I discover c++ programmers > > using Ada... > > The only instance I know of in commercial Ada compilers > which might give rise to such a peculiar claim is the > old obsolete Alsys 386 compiler, which for local > collections (not very common in practice) delayed the > deallocation till scope exit, but even there to say that > the memory was not deallocated is false. The Nighthawk Ada83 compiler deallocated into its own program-wide pool of memory, which would not ever be given back to the *system* until program termination. Out of the 9 or so Ada compilers I have worked with, that's the only one I know that might qualify. (Unless you count the Alsys SMART compilers, which couldn't allocate either.) T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-18 0:00 ` Chris Warwick 1999-01-18 0:00 ` Matthew Heaney 1999-01-18 0:00 ` robert_dewar @ 1999-01-18 0:00 ` dennison 2 siblings, 0 replies; 55+ messages in thread From: dennison @ 1999-01-18 0:00 UTC (permalink / raw) In article <sYyo2.8309$Kg6.62453@news2.telusplanet.net>, warwicks@telusplanet.net (Chris Warwick) wrote: > In article <m3btjzipgf.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > > >The moral of the story is that, in general, when you have a choice, > >don't manipulate references ("pointers") directly. The language > >mandates the argument passing mechanism (by val vs by ref) for types > >passed to a subprogram having a C convention, so the idea is to let the > >compiler generate the reference ("address") automatically. > > I agree with this, but I am finding it difficult to use the Object features of > Ada 95 without using pointers. This situation can up, because the compiler I > am using refuses to pass anything by value, and I am stuck with pointers > passed through the interface code. A lot of the nifty new class-wide programming features require pointers as well. T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-16 0:00 ` Chris Warwick 1999-01-16 0:00 ` Matthew Heaney @ 1999-01-16 0:00 ` robert_dewar 1999-01-18 0:00 ` Chris Warwick 1999-01-16 0:00 ` Simon Wright 2 siblings, 1 reply; 55+ messages in thread From: robert_dewar @ 1999-01-16 0:00 UTC (permalink / raw) In article <GIVn2.8028$Kg6.59441@news2.telusplanet.net>, warwicks@telusplanet.net (Chris Warwick) wrote: > Even from my Ada83 days, the only "safe" way to do > dynamic memory allocation was though the use of local > variables on the stack. If I understand this concept, > then the view is that it is better to point to a newly > allocated buffer, then it is to point to a procedure's > local variable. Exactly, and the reason is to avoid aliasing. This is a very familiar principle. Look at Pascal for example to see the start of this thread of design thinking, which Ada adopted. Ada 95 adds aliased variables, but they should be used with discretion! > Given that most Ada compilers have no way to deallocate > memory, That's simply wrong. Both Ada 83 and Ada 95 have a way to deallocate dynamic memory (Unchecked_Deallocation), and an Ada compiler not implementing this facility is impossible to imagine (and has never existed). > I seem to be trading the potential for a pointer to exist > past the life of the allocated memory for a program > continously allocates memory... Not clear what you are saying here. Certainly pointing to local variables on the stack has very dangerous possible consequences with regard to dangling pointers. The point here is that if you look at any program that uses the keyword ALIASED extensively, then this is almost always an example or importing C style into Ada (see separate thread on importing Pascal into COBOL :-) and is something that should be avoided. Almost always such code can be written to avoid the use of ALIASED, and the result will be improved, better structured code. Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-16 0:00 ` robert_dewar @ 1999-01-18 0:00 ` Chris Warwick 1999-01-18 0:00 ` Matthew Heaney 0 siblings, 1 reply; 55+ messages in thread From: Chris Warwick @ 1999-01-18 0:00 UTC (permalink / raw) In article <77q5m8$e4o$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com wrote: >The point here is that if you look at any program that >uses the keyword ALIASED extensively, then this is almost >always an example or importing C style into Ada (see >separate thread on importing Pascal into COBOL :-) and is >something that should be avoided. Almost always such code >can be written to avoid the use of ALIASED, and the result >will be improved, better structured code. I suppose I could create an active layer (package) on top of the C code and then bury the pointer within the layer... hmmm... is this what you have in mind when you talk about re-structuring the code?? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-18 0:00 ` Chris Warwick @ 1999-01-18 0:00 ` Matthew Heaney 0 siblings, 0 replies; 55+ messages in thread From: Matthew Heaney @ 1999-01-18 0:00 UTC (permalink / raw) warwicks@telusplanet.net (Chris Warwick) writes: > In article <77q5m8$e4o$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com wrote: > > >The point here is that if you look at any program that > >uses the keyword ALIASED extensively, then this is almost > >always an example or importing C style into Ada (see > >separate thread on importing Pascal into COBOL :-) and is > >something that should be avoided. Almost always such code > >can be written to avoid the use of ALIASED, and the result > >will be improved, better structured code. > > I suppose I could create an active layer (package) on top of the C code and > then bury the pointer within the layer... hmmm... is this what you have in > mind when you talk about re-structuring the code?? No. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-16 0:00 ` Chris Warwick 1999-01-16 0:00 ` Matthew Heaney 1999-01-16 0:00 ` robert_dewar @ 1999-01-16 0:00 ` Simon Wright 2 siblings, 0 replies; 55+ messages in thread From: Simon Wright @ 1999-01-16 0:00 UTC (permalink / raw) warwicks@telusplanet.net (Chris Warwick) writes: > I will admit some guilt at being a "reformed" C programmer... But, what I find > odd is the concept that pointing to an object on the "stack" is poor practice. > > Even from my Ada83 days, the only "safe" way to do dynamic memory allocation > was though the use of local variables on the stack. If I understand this > concept, then the view is that it is better to point to a newly allocated > buffer, then it is to point to a procedure's local variable. Given that most > Ada compilers have no way to deallocate memory, I seem to be trading the > potential for a pointer to exist past the life of the allocated memory for a > program continously allocates memory... Most Ada compilers support Ada.Unchecked_Deallocation. Even Ada83 compilers supported Unchecked_Deallocation. Pardon me if I'm wrong, but I think what you're missing may perhaps be the concept of 'in out' (or just 'out') parameters? especially since you can use unconstrained types. procedure Foo is type Buffer_Range is range 1 .. 1024; type Buffer is array (Buffer_Range range <>) of Integer; procedure Process_Buffer (The_Buffer : in out Buffer) is begin for I in The_Buffer'Range loop The_Buffer (I) := Integer (I); -- etc end loop; end Process_Buffer; B : Buffer (20 .. 47); N : Buffer (1 .. 0); -- a zero-length instance begin Process_Buffer (B); Process_Buffer (N); end Foo; ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-09 0:00 ` Chris Warwick 1999-01-09 0:00 ` Simon Wright @ 1999-01-09 0:00 ` Brian Rogoff 1999-01-10 0:00 ` Matthew Heaney 1 sibling, 1 reply; 55+ messages in thread From: Brian Rogoff @ 1999-01-09 0:00 UTC (permalink / raw) On Sat, 9 Jan 1999, Chris Warwick wrote: > In article <771bl9$sla$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com wrote: > > >You can't have it both ways, If you insist on structuring > >your program in a manner that leaves it open to the > >possibilities of dangling pointers, then you have to use > >Unchecked_Access. > > I guess this where I get confused. If I want to pass a pointer amoungst these > functions/procedures I have to define the type at the package level. As a > result there is no way for someone to define an instance of the pointer at a > lower level, i.e., as a local variable within a procedure. Another way to get I'm jumping into the middle of this, so I don't have the context, but one trick I use to define access types at a lower level is to define the access types in a generic package and instantiate them in the scope that I need them. This trick is especially useful with access to subprogram types, which don't permit an Unchecked_Access. > I've got it working... My uneasyness stems from the fact that when I ran into > unchecked_conversion I was able to get someone to explain to me how it really > was "supposed" to work, and once I understood, I agreed. Thus far I still do > not understand how a package can export a "useful" pointer definition... By making the package (a parameterless, if necessary) generic, and instantiating it where you need it? -- Brian ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-09 0:00 ` Brian Rogoff @ 1999-01-10 0:00 ` Matthew Heaney 0 siblings, 0 replies; 55+ messages in thread From: Matthew Heaney @ 1999-01-10 0:00 UTC (permalink / raw) All the compiler is doing when it forbids 'Access is to tell the programmer that it, the compiler, can't make guarantees about the lifetime of designated object. There is nothing magical about 'Unchecked_Access. When you use it, you are not being bad or naughty. It simply means that the programmer is taking the responsibility to guarantee that the designated object lives longer than the access object, instead of relying on the compiler to provide this guarantee. The reasoning that is required in order to prove that an object lives long enough, is not unlike the mental activity that must be performed by the programmer to reason that a loop terminates, or indeed that an algorithm delivers a correct result. Sometimes, thinking is required. It's the same process that C programmers have to follow, whenever they designate an object via a pointer (which is often), because the language itself offers no help. Brian Rogoff <bpr@shell5.ba.best.com> writes: > On Sat, 9 Jan 1999, Chris Warwick wrote: > > In article <771bl9$sla$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com wrote: > > > > >You can't have it both ways, If you insist on structuring > > >your program in a manner that leaves it open to the > > >possibilities of dangling pointers, then you have to use > > >Unchecked_Access. > > > > I guess this where I get confused. If I want to pass a pointer amoungst these > > functions/procedures I have to define the type at the package level. As a > > result there is no way for someone to define an instance of the pointer at a > > lower level, i.e., as a local variable within a procedure. Another way to get > > I'm jumping into the middle of this, so I don't have the context, but one > trick I use to define access types at a lower level is to define the > access types in a generic package and instantiate them in the scope that > I need them. This trick is especially useful with access to subprogram > types, which don't permit an Unchecked_Access. > > > I've got it working... My uneasyness stems from the fact that when I ran into > > unchecked_conversion I was able to get someone to explain to me how it really > > was "supposed" to work, and once I understood, I agreed. Thus far I still do > > not understand how a package can export a "useful" pointer definition... > > By making the package (a parameterless, if necessary) generic, and > instantiating it where you need it? > > -- Brian ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-06 0:00 ` Chris Warwick 1999-01-06 0:00 ` Tom Moran 1999-01-07 0:00 ` robert_dewar @ 1999-01-07 0:00 ` Stephen Leake 1999-01-08 0:00 ` Simon Wright 2 siblings, 1 reply; 55+ messages in thread From: Stephen Leake @ 1999-01-07 0:00 UTC (permalink / raw) "Chris Warwick" <chris.warwick@cdcgy.com> writes: > Stephen Leake wrote in message ... > > >Why does Close_Port need a pointer to a Session? If you are passing > >Session to C code, you should probably use 'Address rather than > >'access. Or, define Close_Port to take an access parameter: As Robert Dewar pointed out, this was bad advice. Aparently too much xmas turkey clogged the arteries to my brain :) The current advice (I believe) is to declare the Ada procedure to take an 'in' or 'in out' parameter, and let the compiler pass this to the C code by reference. This only works if the C code doesn't allow a null pointer as a valid option; the correct way to pass a parameter that can either be a null pointer or a pointer to an object is with an access type parameter, and 'Unchecked_Access. > I am indeed passing this to some C code, and I realize that what I am doing > is cheating, just a little. The reason is I can't seem to get the stuff to > the C function by value, if I pass it by reference its happy, but it barfs > when I try to do it by value. Post the code that fails to "pass by value"; maybe we can tell you what's wrong with it. > My old trick of translating pointers into Ada types by creating a function > to return the record by value also doesn't work... > > >function Close_Port (Session : access Session_Type); > > > >If you really, really need the interface you've given, > >'unchecked_access will eliminate the error message. > > > Thanks, it does indeed eliminate the error, but it leaves me with a bad > taste. Somewhat like resorting to an unchecked_conversion. I agree with the other comments here; the bad taste is from not knowing what will happen to the pointer when you pass it to C. That's why it is "unchecked". > Is there a "proper" way to do this, or am I stuck with the unchecked > solution? If you don't need to be able to pass a null pointer, passing as an 'in' or 'in out' parameter should work, and would be the proper solution. -- Stephe ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-07 0:00 ` Stephen Leake @ 1999-01-08 0:00 ` Simon Wright 0 siblings, 0 replies; 55+ messages in thread From: Simon Wright @ 1999-01-08 0:00 UTC (permalink / raw) Stephen Leake <Stephen.Leake@gsfc.nasa.gov> writes: > I agree with the other comments here; the bad taste is from not > knowing what will happen to the pointer when you pass it to C. That's > why it is "unchecked". Not just to C! for example, in the Booch Components, I have procedure Create_Arc (G : in out Undirected_Graph; A : in out Undirected_Arc'Class; I : Arc_Item; First : in out Undirected_Vertex'Class; Second : in out Undirected_Vertex'Class) is begin Clear (A); A.Rep := new Arc_Node'(Ada.Finalization.Controlled with Item => I, Enclosing => G'Unchecked_Access, -- <<<<<<<<<<<<<<<< From => First.Rep, To => Second.Rep, Next_Incoming => null, Next_Outgoing => null, Count => 1); and the Unchecked_Access is needed because (I suppose) you can't tell at compile time what the scope of the actual for G is. It would certainly be possible (though unnatural) to use this code with the scope of the actual G being less than that of the actual A .. hmm, I guess there's a warning-to-users needed there .. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-05 0:00 ` Chris Warwick 1999-01-05 0:00 ` Stephen Leake @ 1999-01-06 0:00 ` Simon Wright 1999-01-22 0:00 ` Nick Roberts 2 siblings, 0 replies; 55+ messages in thread From: Simon Wright @ 1999-01-06 0:00 UTC (permalink / raw) "Chris Warwick" <chris.warwick@cdcgy.com> writes: > Sorry, perhaps I should have been a little more specific... > > Chris Warwick wrote in message <76s0dp$1v4$1@nntp3.uunet.ca>... > > package Ada_Front_End is > > > > type Session_Type is > > record > > Status : integer := 0; > > end record; > > > > type Session_Ptr_Type is access Session_Type; > > > > function Close_Port (Session : in Session_Ptr_Type) return integer; > > end Ada_Front_End; > > > > procedure Close_Connection is > > Session : aliased constant Ada_Front_End.Session_Type; I guess there must be more to this than you are showing us, because as it stands this Session comes into being here and has no initialization visible .. so it's not clear what the meaning could be (never mind whether it will compile) > > Session_Ptr : Session_Ptr_Type := Session'Access; > > It barfs here, because Session_Ptr_Type has greater scope than Session. My > problem is Close_Port needs a pointer to a Session, so I have to define the > Session_Ptr_Type at the highest level... > > > begin > > Ada_Front_End.Close_Port > > (Session => Session_Ptr); What about (Session => Session'Access) ? (I expect it will fail just the same, and anyway as I said earlier you need to fix this function/procedure thing here)) > > end Close_Connection; ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-05 0:00 ` Chris Warwick 1999-01-05 0:00 ` Stephen Leake 1999-01-06 0:00 ` Simon Wright @ 1999-01-22 0:00 ` Nick Roberts 2 siblings, 0 replies; 55+ messages in thread From: Nick Roberts @ 1999-01-22 0:00 UTC (permalink / raw) Dear Chris, The solution to your problem is (as ever) terrifically simple: declare the variable Session at the same static level as the type Session_Ptr_Type. You do not need a Session_Ptr variable at all. For example: package Connection_Management is procedure Open_Connection; procedure Close_Connection; Connection_Error: exception; end Connection_Management; with Interfaces.C; package body Connection_Management is type Session_Type is record Status : Interfaces.C.int := 0; end record; type Session_Ptr_Type is access all Session_Type; pragma Convention(C,Session_Ptr_Type); The_Session: aliased Session_Type; pragma Volatile(The_Session); function Open_Port (Session: in Session_Ptr_Type) return Interfaces.C.int; pragma Import(C,Open_Port,"OpenPort"); function Close_Port (Session: in Session_Ptr_Type) return Interfaces.C.int; pragma Import(C,Close_Port,"ClosePort"); procedure Open_Connection is begin if Open_Port(The_Session'Access) /= 0 then raise Connection_Error; end if; end Open_Connection; procedure Close_Connection is begin if Close_Port(The_Session'Access) /= 0 then raise Connection_Error; end if; end Close_Connection; end Connection_Management; For clarity, I have renamed Session as The_Session. Of course, all this is to illustrate the declaration and use of a C pointer type in Ada. In reality, the body of the above package would be programmed as follows: with Interfaces.C; package body Connection_Management is type Session_Type is record Status : Interfaces.C.int := 0; end record; The_Session: Session_Type; pragma Volatile(The_Session); function Open_Port (Session: in out Session_Type) return Interfaces.C.int; pragma Import(C,Open_Port,"OpenPort"); function Close_Port (Session: in out Session_Type) return Interfaces.C.int; pragma Import(C,Close_Port,"ClosePort"); procedure Open_Connection is begin if Open_Port(The_Session) /= 0 then raise Connection_Error; end if; end Open_Connection; procedure Close_Connection is begin if Close_Port(The_Session) /= 0 then raise Connection_Error; end if; end Close_Connection; end Connection_Management; Ada automatically converts between an 'in out' parameter and the appropriate C pointer type. Don't forget the Volatile pragma, or your compiler is entitled to do something brown and sticky to you. -- Nick Roberts 2104: Witty remark not found - try again later Chris Warwick wrote in message <76tbvv$ba5$1@nntp3.uunet.ca>... |Sorry, perhaps I should have been a little more specific... | |Chris Warwick wrote in message <76s0dp$1v4$1@nntp3.uunet.ca>... |> package Ada_Front_End is |> |> type Session_Type is |> record |> Status : integer := 0; |> end record; |> |> type Session_Ptr_Type is access Session_Type; |> |> function Close_Port (Session : in Session_Ptr_Type) return integer; |> end Ada_Front_End; |> |> procedure Close_Connection is |> Session : aliased constant Ada_Front_End.Session_Type; |> Session_Ptr : Session_Ptr_Type := Session'Access; | |It barfs here, because Session_Ptr_Type has greater scope than Session. My |problem is Close_Port needs a pointer to a Session, so I have to define the |Session_Ptr_Type at the highest level... | |> begin |> Ada_Front_End.Close_Port |> (Session => Session_Ptr); |> end Close_Connection; ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: How do I get this to work?? 1999-01-04 0:00 How do I get this to work?? Chris Warwick 1999-01-05 0:00 ` Chris Warwick @ 1999-01-05 0:00 ` Tom Moran 1 sibling, 0 replies; 55+ messages in thread From: Tom Moran @ 1999-01-05 0:00 UTC (permalink / raw) > type Session_Ptr_Type is access Session_Type; type Session_Ptr_Type is access all Session_Type; ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~1999-01-22 0:00 UTC | newest] Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-01-04 0:00 How do I get this to work?? Chris Warwick 1999-01-05 0:00 ` Chris Warwick 1999-01-05 0:00 ` Stephen Leake 1999-01-05 0:00 ` Tom Moran 1999-01-06 0:00 ` robert_dewar 1999-01-06 0:00 ` Tom Moran 1999-01-07 0:00 ` robert_dewar 1999-01-07 0:00 ` Tom Moran 1999-01-10 0:00 ` robert_dewar 1999-01-06 0:00 ` Tom Moran 1999-01-07 0:00 ` robert_dewar 1999-01-07 0:00 ` Tom Moran 1999-01-10 0:00 ` robert_dewar 1999-01-10 0:00 ` Tom Moran 1999-01-10 0:00 ` robert_dewar 1999-01-10 0:00 ` robert_dewar 1999-01-10 0:00 ` Pat Rogers 1999-01-10 0:00 ` Tom Moran 1999-01-06 0:00 ` Larry Kilgallen 1999-01-06 0:00 ` Tom Moran 1999-01-06 0:00 ` robert_dewar 1999-01-06 0:00 ` Chris Warwick 1999-01-06 0:00 ` Tom Moran 1999-01-07 0:00 ` robert_dewar 1999-01-09 0:00 ` Chris Warwick 1999-01-09 0:00 ` Simon Wright 1999-01-10 0:00 ` robert_dewar 1999-01-11 0:00 ` Simon Wright 1999-01-16 0:00 ` Chris Warwick 1999-01-16 0:00 ` Matthew Heaney 1999-01-16 0:00 ` robert_dewar 1999-01-18 0:00 ` Chris Warwick 1999-01-18 0:00 ` Matthew Heaney 1999-01-18 0:00 ` robert_dewar 1999-01-18 0:00 ` Tucker Taft 1999-01-19 0:00 ` Chris Warwick 1999-01-19 0:00 ` Stephen Leake 1999-01-19 0:00 ` robert_dewar 1999-01-20 0:00 ` Jeff Carter 1999-01-20 0:00 ` robert_dewar 1999-01-21 0:00 ` Chris Warwick 1999-01-19 0:00 ` Tom Moran 1999-01-18 0:00 ` dennison 1999-01-18 0:00 ` dennison 1999-01-16 0:00 ` robert_dewar 1999-01-18 0:00 ` Chris Warwick 1999-01-18 0:00 ` Matthew Heaney 1999-01-16 0:00 ` Simon Wright 1999-01-09 0:00 ` Brian Rogoff 1999-01-10 0:00 ` Matthew Heaney 1999-01-07 0:00 ` Stephen Leake 1999-01-08 0:00 ` Simon Wright 1999-01-06 0:00 ` Simon Wright 1999-01-22 0:00 ` Nick Roberts 1999-01-05 0:00 ` Tom Moran
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox