* Preventing Unchecked_Deallocation? @ 2012-02-02 23:41 Simon Belmont 2012-02-04 14:40 ` AdaMagica 0 siblings, 1 reply; 37+ messages in thread From: Simon Belmont @ 2012-02-02 23:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-02 23:41 Preventing Unchecked_Deallocation? Simon Belmont @ 2012-02-04 14:40 ` AdaMagica 2012-02-05 16:42 ` Simon Belmont 0 siblings, 1 reply; 37+ messages in thread From: AdaMagica @ 2012-02-04 14:40 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-04 14:40 ` AdaMagica @ 2012-02-05 16:42 ` Simon Belmont 2012-02-06 12:52 ` Julian Leyh ` (3 more replies) 0 siblings, 4 replies; 37+ messages in thread From: Simon Belmont @ 2012-02-05 16:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-05 16:42 ` Simon Belmont @ 2012-02-06 12:52 ` Julian Leyh 2012-02-06 16:05 ` Adam Beneschan 2012-02-06 16:21 ` Adam Beneschan ` (2 subsequent siblings) 3 siblings, 1 reply; 37+ messages in thread From: Julian Leyh @ 2012-02-06 12:52 UTC (permalink / raw) 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 := .... ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-06 12:52 ` Julian Leyh @ 2012-02-06 16:05 ` Adam Beneschan 0 siblings, 0 replies; 37+ messages in thread From: Adam Beneschan @ 2012-02-06 16:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-05 16:42 ` Simon Belmont 2012-02-06 12:52 ` Julian Leyh @ 2012-02-06 16:21 ` Adam Beneschan 2012-02-06 18:34 ` AdaMagica 2012-02-07 0:14 ` Simon Belmont 2012-02-07 6:26 ` Jeffrey Carter 2012-02-07 16:27 ` Robert A Duff 3 siblings, 2 replies; 37+ messages in thread From: Adam Beneschan @ 2012-02-06 16:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-06 16:21 ` Adam Beneschan @ 2012-02-06 18:34 ` AdaMagica 2012-02-07 0:14 ` Simon Belmont 1 sibling, 0 replies; 37+ messages in thread From: AdaMagica @ 2012-02-06 18:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-06 16:21 ` Adam Beneschan 2012-02-06 18:34 ` AdaMagica @ 2012-02-07 0:14 ` Simon Belmont 2012-02-07 2:19 ` Shark8 ` (2 more replies) 1 sibling, 3 replies; 37+ messages in thread From: Simon Belmont @ 2012-02-07 0:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-07 0:14 ` Simon Belmont @ 2012-02-07 2:19 ` Shark8 2012-02-07 16:39 ` Robert A Duff 2012-02-07 11:42 ` Gautier write-only 2012-02-09 2:49 ` Randy Brukardt 2 siblings, 1 reply; 37+ messages in thread From: Shark8 @ 2012-02-07 2:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-07 2:19 ` Shark8 @ 2012-02-07 16:39 ` Robert A Duff 0 siblings, 0 replies; 37+ messages in thread From: Robert A Duff @ 2012-02-07 16:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-07 0:14 ` Simon Belmont 2012-02-07 2:19 ` Shark8 @ 2012-02-07 11:42 ` Gautier write-only 2012-02-07 21:11 ` Simon Belmont 2012-02-09 2:49 ` Randy Brukardt 2 siblings, 1 reply; 37+ messages in thread From: Gautier write-only @ 2012-02-07 11:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-07 11:42 ` Gautier write-only @ 2012-02-07 21:11 ` Simon Belmont 2012-02-07 21:30 ` Robert A Duff 0 siblings, 1 reply; 37+ messages in thread From: Simon Belmont @ 2012-02-07 21:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-07 21:11 ` Simon Belmont @ 2012-02-07 21:30 ` Robert A Duff 2012-02-07 22:23 ` Simon Wright 2012-02-07 23:06 ` Alan Copeland 0 siblings, 2 replies; 37+ messages in thread From: Robert A Duff @ 2012-02-07 21:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-07 21:30 ` Robert A Duff @ 2012-02-07 22:23 ` Simon Wright 2012-02-07 23:07 ` Robert A Duff 2012-02-07 23:06 ` Alan Copeland 1 sibling, 1 reply; 37+ messages in thread From: Simon Wright @ 2012-02-07 22:23 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-07 22:23 ` Simon Wright @ 2012-02-07 23:07 ` Robert A Duff 2012-02-08 8:43 ` Simon Wright 0 siblings, 1 reply; 37+ messages in thread From: Robert A Duff @ 2012-02-07 23:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-07 23:07 ` Robert A Duff @ 2012-02-08 8:43 ` Simon Wright 2012-02-08 15:06 ` Robert A Duff 2012-02-09 2:22 ` Randy Brukardt 0 siblings, 2 replies; 37+ messages in thread From: Simon Wright @ 2012-02-08 8:43 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-08 8:43 ` Simon Wright @ 2012-02-08 15:06 ` Robert A Duff 2012-02-09 2:22 ` Randy Brukardt 1 sibling, 0 replies; 37+ messages in thread From: Robert A Duff @ 2012-02-08 15:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-08 8:43 ` Simon Wright 2012-02-08 15:06 ` Robert A Duff @ 2012-02-09 2:22 ` Randy Brukardt 2012-02-09 7:28 ` Simon Wright 1 sibling, 1 reply; 37+ messages in thread From: Randy Brukardt @ 2012-02-09 2:22 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-09 2:22 ` Randy Brukardt @ 2012-02-09 7:28 ` Simon Wright 0 siblings, 0 replies; 37+ messages in thread From: Simon Wright @ 2012-02-09 7:28 UTC (permalink / raw) "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! ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-07 21:30 ` Robert A Duff 2012-02-07 22:23 ` Simon Wright @ 2012-02-07 23:06 ` Alan Copeland 2012-02-07 23:10 ` Robert A Duff 1 sibling, 1 reply; 37+ messages in thread From: Alan Copeland @ 2012-02-07 23:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-07 23:06 ` Alan Copeland @ 2012-02-07 23:10 ` Robert A Duff 0 siblings, 0 replies; 37+ messages in thread From: Robert A Duff @ 2012-02-07 23:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-07 0:14 ` Simon Belmont 2012-02-07 2:19 ` Shark8 2012-02-07 11:42 ` Gautier write-only @ 2012-02-09 2:49 ` Randy Brukardt 2012-02-09 3:39 ` Jeffrey Carter 2012-02-09 7:37 ` Simon Wright 2 siblings, 2 replies; 37+ messages in thread From: Randy Brukardt @ 2012-02-09 2:49 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-09 2:49 ` Randy Brukardt @ 2012-02-09 3:39 ` Jeffrey Carter 2012-02-09 15:47 ` Adam Beneschan 2012-02-09 7:37 ` Simon Wright 1 sibling, 1 reply; 37+ messages in thread From: Jeffrey Carter @ 2012-02-09 3:39 UTC (permalink / raw) 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 --- ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-09 3:39 ` Jeffrey Carter @ 2012-02-09 15:47 ` Adam Beneschan 2012-02-09 19:16 ` Jeffrey Carter 0 siblings, 1 reply; 37+ messages in thread From: Adam Beneschan @ 2012-02-09 15:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-09 15:47 ` Adam Beneschan @ 2012-02-09 19:16 ` Jeffrey Carter 0 siblings, 0 replies; 37+ messages in thread From: Jeffrey Carter @ 2012-02-09 19:16 UTC (permalink / raw) 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 --- ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-09 2:49 ` Randy Brukardt 2012-02-09 3:39 ` Jeffrey Carter @ 2012-02-09 7:37 ` Simon Wright 2012-02-10 1:08 ` Randy Brukardt 1 sibling, 1 reply; 37+ messages in thread From: Simon Wright @ 2012-02-09 7:37 UTC (permalink / raw) "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). ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-09 7:37 ` Simon Wright @ 2012-02-10 1:08 ` Randy Brukardt 2012-02-10 7:35 ` Simon Wright 0 siblings, 1 reply; 37+ messages in thread From: Randy Brukardt @ 2012-02-10 1:08 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-10 1:08 ` Randy Brukardt @ 2012-02-10 7:35 ` Simon Wright 0 siblings, 0 replies; 37+ messages in thread From: Simon Wright @ 2012-02-10 7:35 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-05 16:42 ` Simon Belmont 2012-02-06 12:52 ` Julian Leyh 2012-02-06 16:21 ` Adam Beneschan @ 2012-02-07 6:26 ` Jeffrey Carter 2012-02-08 8:49 ` Maciej Sobczak 2012-02-07 16:27 ` Robert A Duff 3 siblings, 1 reply; 37+ messages in thread From: Jeffrey Carter @ 2012-02-07 6:26 UTC (permalink / raw) 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 --- ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-07 6:26 ` Jeffrey Carter @ 2012-02-08 8:49 ` Maciej Sobczak 2012-02-08 23:40 ` BrianG 2012-02-09 2:57 ` Randy Brukardt 0 siblings, 2 replies; 37+ messages in thread From: Maciej Sobczak @ 2012-02-08 8:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-08 8:49 ` Maciej Sobczak @ 2012-02-08 23:40 ` BrianG 2012-02-09 2:57 ` Randy Brukardt 1 sibling, 0 replies; 37+ messages in thread From: BrianG @ 2012-02-08 23:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-08 8:49 ` Maciej Sobczak 2012-02-08 23:40 ` BrianG @ 2012-02-09 2:57 ` Randy Brukardt 2012-02-09 7:13 ` Pascal Obry 2012-02-09 8:08 ` Maciej Sobczak 1 sibling, 2 replies; 37+ messages in thread From: Randy Brukardt @ 2012-02-09 2:57 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-09 2:57 ` Randy Brukardt @ 2012-02-09 7:13 ` Pascal Obry 2012-02-10 1:12 ` Randy Brukardt 2012-02-09 8:08 ` Maciej Sobczak 1 sibling, 1 reply; 37+ messages in thread From: Pascal Obry @ 2012-02-09 7:13 UTC (permalink / raw) To: Randy Brukardt 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-09 7:13 ` Pascal Obry @ 2012-02-10 1:12 ` Randy Brukardt 0 siblings, 0 replies; 37+ messages in thread From: Randy Brukardt @ 2012-02-10 1:12 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-09 2:57 ` Randy Brukardt 2012-02-09 7:13 ` Pascal Obry @ 2012-02-09 8:08 ` Maciej Sobczak 2012-02-10 1:18 ` Randy Brukardt 1 sibling, 1 reply; 37+ messages in thread From: Maciej Sobczak @ 2012-02-09 8:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-09 8:08 ` Maciej Sobczak @ 2012-02-10 1:18 ` Randy Brukardt 0 siblings, 0 replies; 37+ messages in thread From: Randy Brukardt @ 2012-02-10 1:18 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Preventing Unchecked_Deallocation? 2012-02-05 16:42 ` Simon Belmont ` (2 preceding siblings ...) 2012-02-07 6:26 ` Jeffrey Carter @ 2012-02-07 16:27 ` Robert A Duff 3 siblings, 0 replies; 37+ messages in thread From: Robert A Duff @ 2012-02-07 16:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2012-02-10 7:35 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-02-02 23:41 Preventing Unchecked_Deallocation? Simon Belmont 2012-02-04 14:40 ` AdaMagica 2012-02-05 16:42 ` Simon Belmont 2012-02-06 12:52 ` Julian Leyh 2012-02-06 16:05 ` Adam Beneschan 2012-02-06 16:21 ` Adam Beneschan 2012-02-06 18:34 ` AdaMagica 2012-02-07 0:14 ` Simon Belmont 2012-02-07 2:19 ` Shark8 2012-02-07 16:39 ` Robert A Duff 2012-02-07 11:42 ` Gautier write-only 2012-02-07 21:11 ` Simon Belmont 2012-02-07 21:30 ` Robert A Duff 2012-02-07 22:23 ` Simon Wright 2012-02-07 23:07 ` Robert A Duff 2012-02-08 8:43 ` Simon Wright 2012-02-08 15:06 ` Robert A Duff 2012-02-09 2:22 ` Randy Brukardt 2012-02-09 7:28 ` Simon Wright 2012-02-07 23:06 ` Alan Copeland 2012-02-07 23:10 ` Robert A Duff 2012-02-09 2:49 ` Randy Brukardt 2012-02-09 3:39 ` Jeffrey Carter 2012-02-09 15:47 ` Adam Beneschan 2012-02-09 19:16 ` Jeffrey Carter 2012-02-09 7:37 ` Simon Wright 2012-02-10 1:08 ` Randy Brukardt 2012-02-10 7:35 ` Simon Wright 2012-02-07 6:26 ` Jeffrey Carter 2012-02-08 8:49 ` Maciej Sobczak 2012-02-08 23:40 ` BrianG 2012-02-09 2:57 ` Randy Brukardt 2012-02-09 7:13 ` Pascal Obry 2012-02-10 1:12 ` Randy Brukardt 2012-02-09 8:08 ` Maciej Sobczak 2012-02-10 1:18 ` Randy Brukardt 2012-02-07 16:27 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox