Preventing Unchecked_Deallocation?

Preventing Unchecked_Deallocation?

[Simon Belmont]

Hey all,

Does anyone know of a clever incantation to prevent the unchecked
deallocation of an access type?  No matter what combination of methods
I use, there doesn't seem to be way to prevent some arbitrary code
from type casting it to a local type, and then freeing it.

-sb

Re: Preventing Unchecked_Deallocation?

[AdaMagica]

Don't understand your problem. However, keep in mind that UD with a
type different from the one with which the objects were allocated is
erroneous.

Re: Preventing Unchecked_Deallocation?

[Simon Belmont]

On Feb 4, 9:40 am, AdaMagica <christ-usch.gr...@t-online.de> wrote:
> Don't understand your problem. However, keep in mind that UD with a
> type different from the one with which the objects were allocated is
> erroneous.

When you say erroneous, do you mean forbidden by the language (i.e. an
exception) or that it will cause undefined operation?  My concern is
that if a unit exposes an access value to other units, any of them may
use UD to delete the object at any time.  Obviously this sort of
behavior would cause the program to quickly crash due to a null
pointer, but all things being equal I would prefer a compile-time
mechanism to prevent the UD outright.  For instance:


package ud is
  function Get return not null access Integer;
end ud;

package body ud is
  type Int_Ptr is access all Integer;
  o : Int_Ptr := new Integer'(42);

  function Get return not null access Integer is
  begin
    return o;
  end Get;

end ud;


procedure test is

  type Fake_Ptr is access all Integer;

  procedure Free is new Ada.Unchecked_Deallocation (Object => Integer,
                                                    Name => Fake_Ptr);

  p : Fake_Ptr;

begin

  p := Fake_Ptr(ud.Get);  -- cast to a local type

  Free (p);  -- phuck the whole program

end test;

-sb

Re: Preventing Unchecked_Deallocation?

[Julian Leyh]

On 5 Feb., 17:42, Simon Belmont <sbelmont...@gmail.com> wrote:
> package ud is
>   function Get return not null access Integer;
> end ud;
>
> package body ud is
>   type Int_Ptr is access all Integer;
>   o : Int_Ptr := new Integer'(42);

use o : constant Int_Ptr := ....

Re: Preventing Unchecked_Deallocation?

[Adam Beneschan]

On Feb 6, 4:52 am, Julian Leyh <jul...@vgai.de> wrote:
> On 5 Feb., 17:42, Simon Belmont <sbelmont...@gmail.com> wrote:
>
> > package ud is
> >   function Get return not null access Integer;
> > end ud;
>
> > package body ud is
> >   type Int_Ptr is access all Integer;
> >   o : Int_Ptr := new Integer'(42);
>
> use o : constant Int_Ptr := ....

Ummm, no.  All that does is prevent the variable "o" from being
modified inside the body of UD.  That means that if Free is an
instance of Unchecked_Deallocation, the body of UD can't call

   Free (o);

but that doesn't prevent

   x := o;       -- where x is a variable
   Free (x);

or

   x := Get;
   Free (x);

And "o" will point to a non-existing object.

                            -- Adam

Re: Preventing Unchecked_Deallocation?

[Adam Beneschan]

On Feb 5, 8:42 am, Simon Belmont <sbelmont...@gmail.com> wrote:
> On Feb 4, 9:40 am, AdaMagica <christ-usch.gr...@t-online.de> wrote:
>
> > Don't understand your problem. However, keep in mind that UD with a
> > type different from the one with which the objects were allocated is
> > erroneous.
>
> When you say erroneous, do you mean forbidden by the language (i.e. an
> exception) or that it will cause undefined operation?  My concern is
> that if a unit exposes an access value to other units, any of them may
> use UD to delete the object at any time.  Obviously this sort of
> behavior would cause the program to quickly crash due to a null
> pointer, but all things being equal I would prefer a compile-time
> mechanism to prevent the UD outright.

I think the solution is not to expose the access type, but have your
package define a private type.  Ada 2012 is supposed to have new
mechanisms that allow packages to define "dereference" operations that
could allow package users to use the same kind of syntax on objects of
private types that they can use on access types.  If you do this, then
it's likely that the package that defines the type can control what
operations are available and not make Unchecked_Deallocation
available.  However, I haven't yet studied the new feature so I can't
say for sure.

As a general rule, though, I believe that if a package does make an
access type visible, users of the package should not try to deallocate
any objects of the type themselves, when objects of the type are
supplied by the package.  Instead, the package should provide
operations to do any needed deallocations (ideally not a "Deallocate"
operation, but perhaps a "No Longer Needed" operation so that it's the
package that defines the type that decides when it's OK to
deallocate).  I don't think the language can prevent package users
from deallocating, except by using private types.  But I'd say that
doing your own Unchecked_Deallocation on an object allocated by
another package (if the documentation doesn't explicitly say it's OK)
is just poor programming, and there's a limit to how much Ada can do
to prevent poor programmers using Unchecked routines from doing
damage.  (Even if you used private types, Ada can't prevent a user
from using Unchecked_Conversion to convert to an access type and then
deallocating it.  And I think I've known some programmers who wouldn't
see anything wrong with doing that, if they believed it would solve
their problem.)

Conceivably, it might be possible to add a "not deallocatable" aspect
to an access type and add language rules to Unchecked_Deallocation and
to the rules on type conversions so that this could be prevent.
However, since the language seems to have been moving in the direction
of making it simpler not to have visible access types at all, I doubt
that ARG would deem worthwhile to add this kind of feature.

                                -- Adam

Re: Preventing Unchecked_Deallocation?

[AdaMagica]

On 6 Feb., 17:21, Adam Beneschan <a...@irvine.com> wrote:

> > When you say erroneous, do you mean forbidden by the language (i.e. an
> > exception) or that it will cause undefined operation?

Unpredictable behaviour (generally not an exception).

> I think the solution is not to expose the access type, but have your
> package define a private type.  Ada 2012 is supposed to have new
> mechanisms that allow packages to define "dereference" operations that
> could allow package users to use the same kind of syntax on objects of
> private types that they can use on access types.  If you do this, then
> it's likely that the package that defines the type can control what
> operations are available and not make Unchecked_Deallocation
> available.  However, I haven't yet studied the new feature so I can't
> say for sure.

See e.g. http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0268-1.txt?rev=1.3
and http://www.adacore.com/2011/06/06/gem-107-preventing-deallocation-for-reference-counted-types/

A further gem will eventually be published with more details about
implicit dereferencing and indexing.

Re: Preventing Unchecked_Deallocation?

[Simon Belmont]

On Feb 6, 11:21 am, Adam Beneschan <a...@irvine.com> wrote:
> On Feb 5, 8:42 am, Simon Belmont <sbelmont...@gmail.com> wrote:
>
> > On Feb 4, 9:40 am, AdaMagica <christ-usch.gr...@t-online.de> wrote:
>
> > > Don't understand your problem. However, keep in mind that UD with a
> > > type different from the one with which the objects were allocated is
> > > erroneous.
>
> > When you say erroneous, do you mean forbidden by the language (i.e. an
> > exception) or that it will cause undefined operation?  My concern is
> > that if a unit exposes an access value to other units, any of them may
> > use UD to delete the object at any time.  Obviously this sort of
> > behavior would cause the program to quickly crash due to a null
> > pointer, but all things being equal I would prefer a compile-time
> > mechanism to prevent the UD outright.
>
> I think the solution is not to expose the access type, but have your
> package define a private type.  Ada 2012 is supposed to have new
> mechanisms that allow packages to define "dereference" operations that
> could allow package users to use the same kind of syntax on objects of
> private types that they can use on access types.  If you do this, then
> it's likely that the package that defines the type can control what
> operations are available and not make Unchecked_Deallocation
> available.  However, I haven't yet studied the new feature so I can't
> say for sure.
>
> As a general rule, though, I believe that if a package does make an
> access type visible, users of the package should not try to deallocate
> any objects of the type themselves, when objects of the type are
> supplied by the package.  Instead, the package should provide
> operations to do any needed deallocations (ideally not a "Deallocate"
> operation, but perhaps a "No Longer Needed" operation so that it's the
> package that defines the type that decides when it's OK to
> deallocate).  I don't think the language can prevent package users
> from deallocating, except by using private types.  But I'd say that
> doing your own Unchecked_Deallocation on an object allocated by
> another package (if the documentation doesn't explicitly say it's OK)
> is just poor programming, and there's a limit to how much Ada can do
> to prevent poor programmers using Unchecked routines from doing
> damage.  (Even if you used private types, Ada can't prevent a user
> from using Unchecked_Conversion to convert to an access type and then
> deallocating it.  And I think I've known some programmers who wouldn't
> see anything wrong with doing that, if they believed it would solve
> their problem.)
>
> Conceivably, it might be possible to add a "not deallocatable" aspect
> to an access type and add language rules to Unchecked_Deallocation and
> to the rules on type conversions so that this could be prevent.
> However, since the language seems to have been moving in the direction
> of making it simpler not to have visible access types at all, I doubt
> that ARG would deem worthwhile to add this kind of feature.
>
>                                 -- Adam

I agree with all your points, and was essentially looking for a way to
enforce this at compile time.  I have casually looked at the implicit
dereferencing in 2012, but from a once-over it seems like it can only
be for visible parts (i.e. access discriminents); the problem is that
the implicit dereference doesn't stop you from explicit dereference,
and you can then cast away any sort of anonymity, constness, or not-
nullness.  It would seem that if everyone is in agreement that doing
something is bad practice and should be avoided the language ought to
have a way to prevent it, but I suppose when you start in with
Unchecked_Anything, the results are by definition unpredictable.

If I were king of Ada, i would just cut through the tricks and add a
new 'reference' type; basically just syntactical sugar for a constant,
not null, auto-dereferenced, optionally limited access type.  It would
cut down on errors, simplify the syntax, and even present room for
compile-time optimizations.  It's strange to me that a language of
such a high level of abstraction when it comes to everything else
still regards access types with the underlying 'address stored in
memory' mentality.

Thank you again

-sb

Re: Preventing Unchecked_Deallocation?

[Shark8]

On Feb 6, 6:14 pm, Simon Belmont <sbelmont...@gmail.com> wrote:
> On Feb 6, 11:21 am, Adam Beneschan <a...@irvine.com> wrote:
>
> It's strange to me that a language of
> such a high level of abstraction when it comes to everything else
> still regards access types with the underlying 'address stored in
> memory' mentality.
>

You know, I remember reading somewhere that Ada chose ACCESS because
it could be implemented as something other than an integer... like a
record (remember the segment:offset pairs on the 286?).

Technically still an "address stored in memory" but far better (IMO)
than the "yeah-its-an-integer" of most other languages.

I seem to also recall a 'trick' for making an access-type "must-
derefrence" by using "FOR ACCESS_TYPE'Size = 0;"

But, in any case, you're probably right that a REFERENCE type (being a
constant,
not null, auto-dereferenced, optionally limited access type) would be
a good addition.

Re: Preventing Unchecked_Deallocation?

[Robert A Duff]

Shark8 <onewingedshark@gmail.com> writes:

> You know, I remember reading somewhere that Ada chose ACCESS because
> it could be implemented as something other than an integer... like a
> record (remember the segment:offset pairs on the 286?).

I've heard things like that, too.  But it makes no sense to me.
How could calling something "access" instead of "pointer" or
"reference" affect its semantics?  It just confuses people.

Pascal calls these things "pointers", and their semantics is
the same as Ada[*] access types, so there's nothing about the
word "pointer" that needs to imply "low-level, hardware
address, address arithmetic, just-an-integer, etc".

[*] Ada 83, that is.  Later versions of Ada added some additional
functionality, some of which is LESS safe than Pascal pointers.

> Technically still an "address stored in memory" but far better (IMO)
> than the "yeah-its-an-integer" of most other languages.

I don't think there's any such implication in most other languages.
After all, C is implemented on 8086 and 80286 using segment:offset
pointers.  And it's possible to implement a bounds-checked version
of C using fat pointers -- but it would be grossly inefficient.

- Bob

Re: Preventing Unchecked_Deallocation?

[Gautier write-only]

On 7 fév, 01:14, Simon Belmont <sbelmont...@gmail.com> wrote:

> If I were king of Ada, i would just cut through the tricks and add a
> new 'reference' type; basically just syntactical sugar for a constant,
> not null, auto-dereferenced, optionally limited access type.  It would
> cut down on errors, simplify the syntax, and even present room for
> compile-time optimizations.  It's strange to me that a language of
> such a high level of abstraction when it comes to everything else
> still regards access types with the underlying 'address stored in
> memory' mentality.

Lol!
Probably if you were the king of Ada you would be in close contact
with the God of the Reference Manuals and discover that in 99% of the
cases you don't even need accesses at all (implicit or explicit, be it
called pointers or reference types) in Ada, and that you also don't
need to bother with null, not null, or dangling or not, or with
allocation, deallocation, or with garbage collection, its activation,
or its absence...
You would enjoy the easy life and look from time to time with a
spyglass the C# developers fighting with users' error boxes.
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address

Re: Preventing Unchecked_Deallocation?

[Simon Belmont]

On Feb 7, 6:42 am, Gautier write-only <gautier_niou...@hotmail.com>
wrote:

> ...in 99% of the cases you don't even need accesses at all

Can you explain this further?  I can envision many more than 1% of
situations where they would be needed, which means I am probably still
stuck in another languages mentality.  If X and Y must both call
primitive operations of Z, then what other options are there?

-sb

Re: Preventing Unchecked_Deallocation?

[Robert A Duff]

Simon Belmont <sbelmont700@gmail.com> writes:

> On Feb 7, 6:42�am, Gautier write-only <gautier_niou...@hotmail.com>
> wrote:
>
>> ...in 99% of the cases you don't even need accesses at all

I'm not sure what that means.  99% of what cases?  I mean,
there are lots of "cases" where you would use an integer,
or an array, or a procedure, or an if_statement, rather
than an access type.

Anyway, whether pointers are needed rarely or often depends
on the application area.

> Can you explain this further?  I can envision many more than 1% of
> situations where they would be needed, which means I am probably still
> stuck in another languages mentality.  If X and Y must both call
> primitive operations of Z, then what other options are there?

I don't understand that last sentence.  You don't need pointers
(access types) to call primitive operations.

In Ada, you need pointers if you want to create linked heap-allocated
data structures.  In the kinds of program I write, that happens often.
You also need pointers if you want to implement size-changing objects.
Not for much else.

It's often a good idea to hide the pointers away in a package,
rather than scattering them all over the program.

- Bob

Re: Preventing Unchecked_Deallocation?

[Simon Wright]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> In Ada, you need pointers if you want to create linked heap-allocated
> data structures.  In the kinds of program I write, that happens often.
> You also need pointers if you want to implement size-changing objects.
> Not for much else.

In order to represent a UML model, I needed limited objects to represent
the elements in the model (instances of Class, DataType, Association,
Operation, Parameter etc) and I wanted to store them in Maps keyed by
name. I didn't see any choice but to use maps of (name -> access
element'class).

Re: Preventing Unchecked_Deallocation?

[Robert A Duff]

Simon Wright <simon@pushface.org> writes:

> In order to represent a UML model, I needed limited objects to represent
> the elements in the model (instances of Class, DataType, Association,
> Operation, Parameter etc) and I wanted to store them in Maps keyed by
> name. I didn't see any choice but to use maps of (name -> access
> element'class).

You could use Ada.Containers.Maps, but there are still access types
under the covers.

- Bob

Re: Preventing Unchecked_Deallocation?

[Simon Wright]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> In order to represent a UML model, I needed limited objects to represent
>> the elements in the model (instances of Class, DataType, Association,
>> Operation, Parameter etc) and I wanted to store them in Maps keyed by
>> name. I didn't see any choice but to use maps of (name -> access
>> element'class).
>
> You could use Ada.Containers.Maps, but there are still access types
> under the covers.

But not for limited objects, surely?

Seems to me that copying is a Bad Thing when dealing with data that
represents objects in the problem domain.

Using limited types is one way of approaching this, but I suppose
another would be apply conventions, such as insisting on 'in out' usage
everywhere??? How do compiler writers deal with symbol tables?

(and I did use Ada.Containers.Maps, a first for me having been involved
with, and on a project using, the Booch Components! Impressive, although
the API is much larger than I needed).

Re: Preventing Unchecked_Deallocation?

[Robert A Duff]

Simon Wright <simon@pushface.org> writes:

>> You could use Ada.Containers.Maps, but there are still access types
>> under the covers.
>
> But not for limited objects, surely?

Right, I missed the "limited" part.
Also, I meant to say Indefinite_Maps, which allow class-wide.

- Bob

Re: Preventing Unchecked_Deallocation?

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m21uq567h7.fsf@pushface.org...
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
...
> Using limited types is one way of approaching this, but I suppose
> another would be apply conventions, such as insisting on 'in out' usage
> everywhere??? How do compiler writers deal with symbol tables?

I can't speak for others, but our records are non-limited. That makes them 
easy to copy for operations like generic instantiation and subprogram 
inheritance where you need to make a near duplicate of a part of a 
symbolable. We do have one record that is limited, and it has been a 
long-term pain to deal with.

OTOH, you'd probably not like the structure much. We didn't hide any 
significant part of the symboltable, because it didn't seem to pay -- there 
are hundreds of different values stored there, and pretty much any operation 
could use any of them. We did use some accessors, but that was solely for 
memory management reasons.

I'm not sure if we'd use the same structure if starting over today.

                                     Randy.

Re: Preventing Unchecked_Deallocation?

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:m21uq567h7.fsf@pushface.org...
>> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> ...
>> Using limited types is one way of approaching this, but I suppose
>> another would be apply conventions, such as insisting on 'in out' usage
>> everywhere??? How do compiler writers deal with symbol tables?
[...]
> OTOH, you'd probably not like the structure much. We didn't hide any
> significant part of the symboltable, because it didn't seem to pay --
> there are hundreds of different values stored there, and pretty much
> any operation could use any of them. We did use some accessors, but
> that was solely for memory management reasons.

Sounds like a good scheme to me; 'private' isn't a bad default position,
but common sense needs to rule!

Re: Preventing Unchecked_Deallocation?

[Alan Copeland]

On Feb 7, 4:30 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> I don't understand that last sentence.  You don't need pointers
> (access types) to call primitive operations.

Sure, but from a practical standpoint, what other choice is there?
You can't save the actual object Z off into an element of both X and Y
(otherwise you would have two separate objects), so you have to save
an access value.  That way primitive ops of X and Y can both call
primitive ops on the same Z.  Unless I'm missing something...


-sb

Re: Preventing Unchecked_Deallocation?

[Robert A Duff]

Alan Copeland <acopeland01@gmail.com> writes:

> On Feb 7, 4:30�pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>> I don't understand that last sentence. �You don't need pointers
>> (access types) to call primitive operations.
>
> Sure, but from a practical standpoint, what other choice is there?
> You can't save the actual object Z off into an element of both X and Y
> (otherwise you would have two separate objects), so you have to save
> an access value.  That way primitive ops of X and Y can both call
> primitive ops on the same Z.  Unless I'm missing something...

If you want X and Y to share the same Z, then yes, they have to
point at it in some way.  But I still don't see what that has
to do with primitive ops.

You also often need pointers when working with class-wide
objects (you can't have a component type T'Class,
directly).

- Bob

Re: Preventing Unchecked_Deallocation?

[Randy Brukardt]

"Simon Belmont" <sbelmont700@gmail.com> wrote in message 
news:26e4f2a4-edae-4e37-8697-f2390e636a21@z31g2000vbt.googlegroups.com...

>I agree with all your points, and was essentially looking for a way to
>enforce this at compile time.

One way to do this is to use the Restriction (No_Dependence => 
Unchecked_Deallocation), but that of course will prevent anyone from using 
it, which might be going too far. (But not if you are using Ada 2012 
subpools for storage management.)

>  I have casually looked at the implicit
> dereferencing in 2012, but from a once-over it seems like it can only
> be for visible parts (i.e. access discriminents); the problem is that
> the implicit dereference doesn't stop you from explicit dereference,
> and you can then cast away any sort of anonymity, constness, or not-
> nullness.

The entire point is that you can (at least potentially) write the 
dereference. But what you can't do is assign the access discriminant to most 
other access types, because the accessibility check will fail. It can only 
be assigned to some type that will live less long than the object with the 
access discriminant (which usually will be *very* short-lived).

If you don't need (visible) dereferences at all, you should definitely use a 
handle type like the Cursor type of Ada Containers. Indeed, I think that the 
vast majority of the time, you should simply use the Cursor type directly 
(putting the objects into appropriate instances of the containers). There 
you don't have any visible access types (and any existence of them is easily 
detected with tools, see below).

As for the concern about using Unchecked_Deallocation on a local access 
type: it's always bad practice to deallocate something for a type other than 
the one it was allocated for. And, sure, the compiler can't detect this. But 
this is just one out of dozens of ways that a malicious programmer could 
damage your application. There is no way that Ada could possibly prevent 
them all without becoming far too restrictive to be able to accomplish 
anything. (Example: SPARK.)

There is always an important role to play for the culture and/or management 
of an organization. Both the culture and rules (enforced with external tools 
like AdaControl) should minimize the possibility of rouge programmers. But 
no one can prevent intentional maliciousness; at best you can only minimize 
it.

It probably was a mistake to allow allocations for general access types (and 
by definition, if there were no allocations, there could be no 
DEallocations). [It is best is allocations are done for a pool-specific type 
and converted to the general access type as needed.] But it's way too late 
to change that now, it surely would break many existing Ada 95 programs.

> It would seem that if everyone is in agreement that doing
>something is bad practice and should be avoided the language ought to
>have a way to prevent it, but I suppose when you start in with
>Unchecked_Anything, the results are by definition unpredictable.

Exactly.

>If I were king of Ada, i would just cut through the tricks and add a
>new 'reference' type; basically just syntactical sugar for a constant,
>not null, auto-dereferenced, optionally limited access type.  It would
>cut down on errors, simplify the syntax, and even present room for
>compile-time optimizations.  It's strange to me that a language of
>such a high level of abstraction when it comes to everything else
>still regards access types with the underlying 'address stored in
>memory' mentality.

We looked at the possibility for Ada 2012, but adding a new kind of access 
type that was "just a little bit different" than the existing ones did not 
look very appealing. Part of the problem is a completely new kind of type 
cannot do anything to make Ada simpler, because all of the old kinds of 
types are still there and still needed. (It's not like you can replace 
allocations with a "ref" type that doesn't support allocations, and 
allocations are still going to be needed.)

[Also, the sort of type you define is essentially a standard private type --  
we surely don't need a new language feature for that! It's only interesting 
if it has some access-like behavior.]

Another problem is that a "limited" access type (another idea we looked at) 
would be something totally new: there are no elementary limited types in Ada 
today. (A limited private type completed with an elementary type is still 
considered composite.) For instance, an immutably limited type (which this 
probably would be) is always passed by reference, something we clearly don't 
want for a reference type.

So we'd be looking at major surgury to the language, and no major benefit. 
Moreover, when we studied the needed accessibility rules, it turned out that 
they were essentially identical to the ones for access discriminants. Thus 
we decided to just add some "sugar" to make access discriminants usable, 
rather than adding a new type.

                                               Randy.

Re: Preventing Unchecked_Deallocation?

[Jeffrey Carter]

On 02/08/2012 07:49 PM, Randy Brukardt wrote:
>
> rouge programmers

Wow. Even makeup has software in it these days.

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus
54

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Preventing Unchecked_Deallocation?

[Adam Beneschan]

On Feb 8, 7:39 pm, Jeffrey Carter <spam.jrcarter....@spam.not.acm.org>
wrote:
> On 02/08/2012 07:49 PM, Randy Brukardt wrote:
>
>
>
> > rouge programmers
>
> Wow. Even makeup has software in it these days.

I can see how this would be useful.  You could have it compute the
best R, G, and B values or use a color selection widget instead of
having to sit at the Clinique counter for an hour trying to pick the
perfect shade.

Not that I'd know anything about it.

By the way, did you pick the .sig, or was it chosen at random?  If it
was random, it seems quite an amazing coincidence that it picked this
one for this response.

                             -- Adam


> --
> Jeff Carter
> "I'm a lumberjack and I'm OK."
> Monty Python's Flying Circus
> 54

Re: Preventing Unchecked_Deallocation?

[Jeffrey Carter]

On 02/09/2012 08:47 AM, Adam Beneschan wrote:
>
> I can see how this would be useful.  You could have it compute the
> best R, G, and B values or use a color selection widget instead of
> having to sit at the Clinique counter for an hour trying to pick the
> perfect shade.

Sure. But I doubt we'd call that "rouge". More likely, it would be universal 
makeup, applied to multiple regions, and taking different colors depending on 
where on the body it was located.

> By the way, did you pick the .sig, or was it chosen at random?  If it
> was random, it seems quite an amazing coincidence that it picked this
> one for this response.

It's random, selected when I log on to my computer and remaining the same for 
all messages until I log off.

-- 
Jeff Carter
"IMHO, Interfaces are worthless."
Randy Brukardt
117

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Preventing Unchecked_Deallocation?

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> If you don't need (visible) dereferences at all, you should definitely
> use a handle type like the Cursor type of Ada Containers. Indeed, I
> think that the vast majority of the time, you should simply use the
> Cursor type directly (putting the objects into appropriate instances
> of the containers). There you don't have any visible access types (and
> any existence of them is easily detected with tools, see below).

If you mean that the link from object A to object B should be a Cursor
to the Container with the B's in it, will that Cursor retain its
validity if I update the B Container? (by, say, adding another B).

Re: Preventing Unchecked_Deallocation?

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m2lioc4fu9.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> If you don't need (visible) dereferences at all, you should definitely
>> use a handle type like the Cursor type of Ada Containers. Indeed, I
>> think that the vast majority of the time, you should simply use the
>> Cursor type directly (putting the objects into appropriate instances
>> of the containers). There you don't have any visible access types (and
>> any existence of them is easily detected with tools, see below).
>
> If you mean that the link from object A to object B should be a Cursor
> to the Container with the B's in it, will that Cursor retain its
> validity if I update the B Container? (by, say, adding another B).

Yes, of course, that's required by the definition of cursors (for instance, 
see A.18.3(2/2) for the linked list container). It does become "invalid" if 
the B is points at is deleted (in which case it points to nothing, of 
course) or if the entire container is finalized (again, it points to 
nothing). Using "invalid" cursors is a bounded error in most circumstances; 
one would hope that most containers catch it (and raise Program_Error) but 
it's not required (making the pointerness visible again, unfortunately). One 
reason that's it's not required is that it isn't reasonable to detect 
cursors that point at destroyed containers - the memory might be deallocated 
and reused, and once that happens, checks are unreliable.

It would be possible (in a custom container) to prevent all dangling 
cursors, but it would require making cursors controlled and keeping track of 
all of them in the container (so if the container changes, it can search out 
any dead cursors and invalidate them). The id matching check that Janus/Ada 
uses catches about 99% of dangling cursors and is far cheaper -- but if you 
need a guarentee, even that is possible.

                                                   Randy.


                                       Randy. 

Re: Preventing Unchecked_Deallocation?

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:m2lioc4fu9.fsf@pushface.org...
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>
>>> If you don't need (visible) dereferences at all, you should
>>> definitely use a handle type like the Cursor type of Ada
>>> Containers. Indeed, I think that the vast majority of the time, you
>>> should simply use the Cursor type directly (putting the objects into
>>> appropriate instances of the containers). There you don't have any
>>> visible access types (and any existence of them is easily detected
>>> with tools, see below).
>>
>> If you mean that the link from object A to object B should be a
>> Cursor to the Container with the B's in it, will that Cursor retain
>> its validity if I update the B Container? (by, say, adding another
>> B).
>
> Yes, of course, that's required by the definition of cursors (for
> instance, see A.18.3(2/2) for the linked list container).

Excellent, thanks.

Re: Preventing Unchecked_Deallocation?

[Jeffrey Carter]

On 02/05/2012 09:42 AM, Simon Belmont wrote:
>
> package ud is
>    function Get return not null access Integer;
> end ud;

A basic design rule is: the reserved word access must not appear in the visible 
part of a package specification. If you follow this rule, I think your problem 
will disappear.

-- 
Jeff Carter
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail
04

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Preventing Unchecked_Deallocation?

[Maciej Sobczak]

On 7 Lut, 07:26, Jeffrey Carter <spam.jrcarter....@spam.not.acm.org>
wrote:

> A basic design rule is: the reserved word access must not appear in the visible
> part of a package specification.

Don't worry. It will appear in the user package, where yours is
withed.
The smart user will define his own access types and will make pointers
from your objects at the nearest opportunity and there's lots of them
if the type in question is, for example, tagged.

> If you follow this rule, I think your problem
> will disappear.

This rule will irritate the user, because it will make creating
pointers one line more difficult. ;-)

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Preventing Unchecked_Deallocation?

[BrianG]

On 02/08/2012 03:49 AM, Maciej Sobczak wrote:
> On 7 Lut, 07:26, Jeffrey Carter<spam.jrcarter....@spam.not.acm.org>
> wrote:
>
>> A basic design rule is: the reserved word access must not appear in the visible
>> part of a package specification.
>
> Don't worry. It will appear in the user package, where yours is
> withed.
> The smart user will define his own access types and will make pointers
> from your objects at the nearest opportunity and there's lots of them
> if the type in question is, for example, tagged.
>
>> If you follow this rule, I think your problem
>> will disappear.
>
> This rule will irritate the user, because it will make creating
> pointers one line more difficult. ;-)
>
> --
> Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

I'm not sure I agree with those rules (for all cases), but if the only 
pointer are user-defined, it would be rather difficult for the user to 
deallocate items allocated by the library - which I believe was the 
original problem.

(Then again, throw in Unchecked_Conversion and anything can be 
deallocated, even I : Integer := 0; which makes just as much sense as 
deallocating someone else's pointer.)

-- 
---
BrianG
000
@[Google's email domain]
.com

Re: Preventing Unchecked_Deallocation?

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:ca07bff2-cb4f-4cd4-a191-249cb229840b@c20g2000vbb.googlegroups.com...
> On 7 Lut, 07:26, Jeffrey Carter <spam.jrcarter....@spam.not.acm.org>
> wrote:
>
>> A basic design rule is: the reserved word access must not appear in the 
>> visible
>> part of a package specification.
>
> Don't worry. It will appear in the user package, where yours is
> withed.
> The smart user will define his own access types and will make pointers
> from your objects at the nearest opportunity and there's lots of them
> if the type in question is, for example, tagged.

There is absolutely no *requirement* to use access types with tagged types. 
Certainly a lot of uses will work just fine with statically allocated 
objects (for instance, Claw) or by putting them in instances of 
Ada.Containers.

And, as someone one else noted, if the client wants to declare a bunch of 
access types, that's just fine. Then it's their problem to keep track of the 
storage management needed; and they can't damage the library by doing an 
unexpected Unchecked_Deallocation (the library probably expecting objects to 
disappear at any time, and already handling such cases -- again, like Claw 
does). In addition, by letting the client use whatever storage management 
that makes the most sense (pools, subpools, containers, static allocation), 
the library has the most possible flexibility.

Over use of access types in OOP designs is a "feature" of other programming 
language designs (i.e. C++), but there is no need for Ada designers to make 
such mistakes.

My personal theory is the only reason for an Ada 95 program to use "access" 
in a specification is to get the effect of "in out" parameters for 
functions, and that's finally fixed for Ada 2012. I don't think there *ever* 
is a reason to dispatch directly on an access type -- in large part because 
it is a lie, what's really happening is that you're dispatching on 
"Ptr.all", and as such you should say that in the code (it's only 4 extra 
characters, but it makes a world of difference in understandability).

I recommend looking at the design of Claw to see how it can be done.

                                                Randy.

Re: Preventing Unchecked_Deallocation?

[Pascal Obry]

Randy,

> My personal theory is the only reason for an Ada 95 program to use "access" 
> in a specification is to get the effect of "in out" parameters for 
> functions, and that's finally fixed for Ada 2012. I don't think there *ever* 

You also need access type for the Distributed Annex. And this is still
needed with Ada 2012 and will probably forever. But we also want to
distinguish between access type and dynamic allocation. My distributed
application have access types but no dynamic allocation.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Preventing Unchecked_Deallocation?

[Randy Brukardt]

"Pascal Obry" <pascal@obry.net> wrote in message 
news:4F337215.3050802@obry.net...
> Randy,
>
>> My personal theory is the only reason for an Ada 95 program to use 
>> "access"
>> in a specification is to get the effect of "in out" parameters for
>> functions, and that's finally fixed for Ada 2012. I don't think there 
>> *ever*
>
> You also need access type for the Distributed Annex. And this is still
> needed with Ada 2012 and will probably forever.

Yes and no: you can't alway marshall an access value, and it actually makes 
more sense to marshall the designated object. (But I admit I don't have any 
experience in this area - I've always used sockets - so I'll stop before I 
dig a deeper hole. ;-)

> But we also want to
> distinguish between access type and dynamic allocation. My distributed
> application have access types but no dynamic allocation.

Right, and that's why I said that general access types shouldn't have had 
any allocation at all. It would have been easy enough to do conversions in 
the case that it was needed, and it would prevent the erroneous execution 
problems with deallocation of a general access value. (It only works if it 
is from the "right" pool, and there is no way to guarantee that if 
statically allocated objects also can be used.)

                                     Randy.

Re: Preventing Unchecked_Deallocation?

[Maciej Sobczak]

On 9 Lut, 03:57, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> > The smart user will define his own access types and will make pointers
> > from your objects at the nearest opportunity and there's lots of them
> > if the type in question is, for example, tagged.
>
> There is absolutely no *requirement* to use access types with tagged types.

Tagged types are aliased, which allows to obtain access values from
their objects, now there is only one step to
Unchecked_Deallocation. :-)

And this is what I had in mind - it is not possible to completely
defend against stupidity and if the user really wants, he will
deallocate his own pointers to your own objects, even if you have no
access types in your package specs.

Putting it in other words: make something idiot proof and somebody
will invent better idiots.

Other than that, I fully agree that access types are not needed in Ada
as much as they are in other languages.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Preventing Unchecked_Deallocation?

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:5d25ffd0-a73e-48c6-aac1-d5e3b00c4e0a@l1g2000vbc.googlegroups.com...
> On 9 Lut, 03:57, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
>> > The smart user will define his own access types and will make pointers
>> > from your objects at the nearest opportunity and there's lots of them
>> > if the type in question is, for example, tagged.
>>
>> There is absolutely no *requirement* to use access types with tagged 
>> types.
>
> Tagged types are aliased, which allows to obtain access values from
> their objects, now there is only one step to
> Unchecked_Deallocation. :-)
>
> And this is what I had in mind - it is not possible to completely
> defend against stupidity and if the user really wants, he will
> deallocate his own pointers to your own objects, even if you have no
> access types in your package specs.
>
> Putting it in other words: make something idiot proof and somebody
> will invent better idiots.

Well, as I said, a library needs to expect the objects it exports to 
disappear at any time. If that's done (often that means the objects have to 
be controlled, so they can be removed from internal data structures before 
they're gone), then the client can deallocate to their heart's content 
without damaging the the library. (Remember, Ada finalizes when 
Unchecked_Deallocation is called. Same if you use the new subpool 
mechanisms, or containers, or static allocation.)

We took this approach in Claw, simply because I didn't relish having to 
explain to users that their "bug" was caused by their misuse of the library. 
So we tried to "idiot-proof" it as much as possible.

You're of course right that there always is a bigger idiot out there, but 
nothing semi-reasonable should be crashing reusable libraries. (One-time use 
things is a different story, but be careful - a lot of one-time use things 
tend to stick around for a long time.)

                                                         Randy.

Re: Preventing Unchecked_Deallocation?

[Robert A Duff]

Simon Belmont <sbelmont700@gmail.com> writes:

> When you say erroneous, do you mean forbidden by the language (i.e. an
> exception)

No.

>... or that it will cause undefined operation?

Yes.  I suggest you look up the definition of "erroneous"
in the Ada RM.  It doesn't mean what it means in normal English.
I'm planning to write an AdaCore "gem" on this confusing subject
one of these days.

Ada's "erroneous behavior" is roughly equivalent to C's "undefined
behavior".

>...My concern is
> that if a unit exposes an access value to other units, any of them may
> use UD to delete the object at any time.  Obviously this sort of
> behavior would cause the program to quickly crash due to a null
> pointer, ...

That's not obvious!  It might crash slowly.  Worst of all,
it might not crash -- it might do exactly what you wanted,
and now you have a latent bug that might rear it's ugly
head years later.

As others have suggested, the usual solution is to use
a private type.

You could also have a configuration pragma:

    pragma Restrictions(No_Dependence => Ada.Unchecked_Deallocation);

or the GNAT-specific:

    pragma Restriction_Warnings(No_Dependence => Ada.Unchecked_Deallocation);

The latter is more flexible.

- Bob