How do I get this to work??

How do I get this to work??

[Chris Warwick]

   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;

Re: How do I get this to work??

[Tom Moran]

> type Session_Ptr_Type is access Session_Type;
 type Session_Ptr_Type is access all Session_Type;

Re: How do I get this to work??

[Chris Warwick]

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;
>
>

Re: How do I get this to work??

[Stephen Leake]

"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

Re: How do I get this to work??

[Tom Moran]

>... 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.  

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[Tom Moran]

>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.

Re: How do I get this to work??

[Tom Moran]

>Also, what makes you think that an access type is any more
>portable? 
Experience.

Re: How do I get this to work??

[Larry Kilgallen]

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

Re: How do I get this to work??

[Tom Moran]

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.

Re: How do I get this to work??

[Chris Warwick]

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?

Re: How do I get this to work??

[Tom Moran]

>>'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.

Re: How do I get this to work??

[Simon Wright]

"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;

Re: How do I get this to work??

[Stephen Leake]

"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

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[Tom Moran]

>"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 ****.

Re: How do I get this to work??

[Tom Moran]

>experience with obsolete 286
>based segmented architectures
Oh, it goes back before that.  At least to Burroughs architectures,
etc.

Re: How do I get this to work??

[Simon Wright]

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 ..

Re: How do I get this to work??

[Chris Warwick]

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...

Re: How do I get this to work??

[Brian Rogoff]

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

Re: How do I get this to work??

[Simon Wright]

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.

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[Pat Rogers]

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).

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[Tom Moran]

>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.

Re: How do I get this to work??

[Matthew Heaney]

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

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[Tom Moran]

>  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.

Re: How do I get this to work??

[Simon Wright]

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!

Re: How do I get this to work??

[Chris Warwick]

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...

Re: How do I get this to work??

[Matthew Heaney]

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

Re: How do I get this to work??

[Simon Wright]

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;

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[dennison]

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    

Re: How do I get this to work??

[dennison]

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    

Re: How do I get this to work??

[Tucker Taft]

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

Re: How do I get this to work??

[Chris Warwick]

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.

Re: How do I get this to work??

[Chris Warwick]

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??

Re: How do I get this to work??

[Matthew Heaney]

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

Re: How do I get this to work??

[Matthew Heaney]

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.

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[Chris Warwick]

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...

Re: How do I get this to work??

[Tom Moran]

>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.

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[Stephen Leake]

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

Re: How do I get this to work??

[robert_dewar]

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    

Re: How do I get this to work??

[Jeff Carter]

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

Re: How do I get this to work??

[Chris Warwick]

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...

Re: How do I get this to work??

[Nick Roberts]

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;