* Ada 2012 : aliased parameters ? @ 2011-03-28 11:47 Yannick Duchêne (Hibou57) 2011-03-28 11:56 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-03-28 11:47 UTC (permalink / raw) Hello, I was looking at what the Ada 2012 reference looks like so far, and especially at all the “Extensions to Ada 2005” sections. In “Subprogram Declarations” there is such an extension. Quote from Ada 2012: Parameters can now be explicitly aliased, allowing parts of function results to designate parameters and forcing by-reference parameter passing. I'm not sure I've understood. What was wrong with access type parameters ? I don't see a reason why aliased parameters may be required (and don't feel this can be clean). Well, why not in/out parameter for functions, as things like test-and-set are common idioms, but I really can't figure why this one in particular was required. I may look at the related AI later, but it's long (so I will deffer it). A quick overview of good reasons from someone who know ? -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-03-28 11:47 Ada 2012 : aliased parameters ? Yannick Duchêne (Hibou57) @ 2011-03-28 11:56 ` Dmitry A. Kazakov 2011-03-29 3:04 ` Randy Brukardt 2011-03-28 11:56 ` AdaMagica 2011-03-29 3:16 ` Randy Brukardt 2 siblings, 1 reply; 18+ messages in thread From: Dmitry A. Kazakov @ 2011-03-28 11:56 UTC (permalink / raw) On Mon, 28 Mar 2011 13:47:22 +0200, Yannick Duch�ne (Hibou57) wrote: > Quote from Ada 2012: > > Parameters can now be explicitly aliased, allowing parts of > function results to designate parameters and forcing > by-reference parameter passing. Interesting. How to force by-reference something allocated in a register? Yes one could copy the actual value and then pass a reference to the copy, but that is not what I would call "by-reference." -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-03-28 11:56 ` Dmitry A. Kazakov @ 2011-03-29 3:04 ` Randy Brukardt 0 siblings, 0 replies; 18+ messages in thread From: Randy Brukardt @ 2011-03-29 3:04 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 794 bytes --] "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:fkeyxg5zhwig.1hrc0cluxh1r2$.dlg@40tude.net... > On Mon, 28 Mar 2011 13:47:22 +0200, Yannick Duch�ne (Hibou57) wrote: > >> Quote from Ada 2012: >> >> Parameters can now be explicitly aliased, allowing parts of >> function results to designate parameters and forcing >> by-reference parameter passing. > > Interesting. How to force by-reference something allocated in a register? The thing passed has to be aliased or tagged (of course), so the compiler just has to avoid allocating them in a register. Standard stuff. > Yes one could copy the actual value and then pass a reference to the copy, > but that is not what I would call "by-reference." Neither do we. Randy. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-03-28 11:47 Ada 2012 : aliased parameters ? Yannick Duchêne (Hibou57) 2011-03-28 11:56 ` Dmitry A. Kazakov @ 2011-03-28 11:56 ` AdaMagica 2011-03-29 18:22 ` Florian Weimer 2011-03-29 3:16 ` Randy Brukardt 2 siblings, 1 reply; 18+ messages in thread From: AdaMagica @ 2011-03-28 11:56 UTC (permalink / raw) Aliased parameters are meant to cure a deficiency in e.g. containers. With current Ada, it's awkward to replace an element of a container. Now if you make the curser an aliased parameter, the function result may dereference safely the cursor, since the cursor and the result are tightly coupled, i.e. the cursor cannot be changed as long as the function result exists: function Get (Pos: aliased Cursor) return access Element; This is the idea. The syntax in this example might not be correct. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-03-28 11:56 ` AdaMagica @ 2011-03-29 18:22 ` Florian Weimer 2011-03-29 18:34 ` Shark8 2011-03-30 0:12 ` Randy Brukardt 0 siblings, 2 replies; 18+ messages in thread From: Florian Weimer @ 2011-03-29 18:22 UTC (permalink / raw) * AdaMagica: > Aliased parameters are meant to cure a deficiency in e.g. containers. > With current Ada, it's awkward to replace an element of a container. > > Now if you make the curser an aliased parameter, the function result > may dereference safely the cursor, since the cursor and the result are > tightly coupled, But this is already the case in Ada 2005. The lifetime of passed-in objects extends beyond the immediate need for evaluating the expression: | Leaving an execution happens immediately after its completion, | except in the case of a _master_: the execution of a body other than | a package_body; the execution of a statement; or the evaluation of | an expression, function_call, or range that is not part of an | enclosing expression, function_call, range, or simple_statement | other than a simple_return_statement. This is from 7.6.1(3/2). I've written experimental code which depends on this, providing a syntactically convenient and efficient form of variadic subprograms. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-03-29 18:22 ` Florian Weimer @ 2011-03-29 18:34 ` Shark8 2011-03-29 19:35 ` Florian Weimer 2011-03-30 0:12 ` Randy Brukardt 1 sibling, 1 reply; 18+ messages in thread From: Shark8 @ 2011-03-29 18:34 UTC (permalink / raw) On Mar 29, 12:22 pm, Florian Weimer <f...@deneb.enyo.de> wrote: > > I've written experimental code which depends on this, providing a > syntactically convenient and efficient form of variadic subprograms. Could you post an example thereof? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-03-29 18:34 ` Shark8 @ 2011-03-29 19:35 ` Florian Weimer 0 siblings, 0 replies; 18+ messages in thread From: Florian Weimer @ 2011-03-29 19:35 UTC (permalink / raw) * Shark8: > On Mar 29, 12:22�pm, Florian Weimer <f...@deneb.enyo.de> wrote: >> >> I've written experimental code which depends on this, providing a >> syntactically convenient and efficient form of variadic subprograms. > > Could you post an example thereof? I think I already did, in a previous thread, but here's my example code. I don't know why Value'Size is so large. with System; with Ada.Finalization; package Variadic is type Value is limited private; function "+" (V : Integer) return Value; function "+" (V : Long_Float) return Value; function "+" (V : String) return Value; type Argument_Array is array (Positive range <>) of Value; procedure Call (Target : String; Arguments : Argument_Array); private type Value_Kind is (None, Integer_Kind, Float_Kind, String_Kind); type String_Holder is new Ada.Finalization.Limited_Controlled with record Pointer : System.Address; Length : Natural; end record; procedure Finalize (X : in out String_Holder); type Value_Internal (Kind : Value_Kind := None) is record case Kind is when None => null; when Integer_Kind => Integer_Value : Integer; when Float_Kind => Float_Value : Long_Float; when String_Kind => String_Value : String_Holder; end case; end record; type Value is limited record Internal : Value_Internal; end record; end Variadic; with Interfaces.C; with Ada.Text_IO; package body Variadic is function "+" (V : Integer) return Value is begin return (Internal => (Kind => Integer_Kind, Integer_Value => V)); end "+"; function "+" (V : Long_Float) return Value is begin return (Internal => (Kind => Float_Kind, Float_Value => V)); end "+"; function "+" (V : String) return Value is function C_Malloc (Size : Interfaces.C.Size_T) return System.Address; pragma Import (C, C_Malloc, "malloc"); Pointer : constant System.Address := C_Malloc(V'Length); subtype Str is String (V'Range); S : Str; for S'Address use Pointer; begin S := V; return (Internal => (Kind => String_Kind, String_Value => (Ada.Finalization.Limited_Controlled with Pointer => Pointer, Length => V'Length))); end "+"; procedure Call (Target : String; Arguments : Argument_Array) is use Ada.Text_IO; package Integer_IO is new Ada.Text_IO.Integer_IO (Integer); use Integer_IO; package Float_IO is new Ada.Text_IO.Float_IO (Long_Float); use Float_IO; begin Put ("CALL: "); Put_Line (Target); for J in Arguments'Range loop Put (" "); declare Arg : Value_Internal renames Arguments (J).Internal; begin case Arg.Kind is when None => Put ("NONE"); when Integer_Kind => Put ("INTEGER "); Put (Arg.Integer_Value); when Float_Kind => Put ("FLOAT "); Put (Arg.Float_Value); when String_Kind => Put ("STRING "); declare subtype Str is String (1 .. Arg.String_Value.Length); S : Str; for S'Address use Arg.String_Value.Pointer; begin Put (S); end; end case; end; New_Line; end loop; end Call; procedure Finalize (X : in out String_Holder) is procedure C_Free (Ptr : System.address); pragma Import (C, C_Free, "free"); begin C_Free (X.Pointer); X.Pointer := System.Null_Address; end Finalize; end Variadic; with Ada.Text_IO; use Ada.Text_IO; with Variadic; use Variadic; procedure Variadic_Test is begin Put ("Value'Size: "); Put_Line (Integer'Image (Value'Size)); Call ("Foo", (+ 1, + 2.0, + "3.")); end Variadic_Test; ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-03-29 18:22 ` Florian Weimer 2011-03-29 18:34 ` Shark8 @ 2011-03-30 0:12 ` Randy Brukardt 1 sibling, 0 replies; 18+ messages in thread From: Randy Brukardt @ 2011-03-30 0:12 UTC (permalink / raw) "Florian Weimer" <fw@deneb.enyo.de> wrote in message news:87lizxiy6c.fsf@mid.deneb.enyo.de... >* AdaMagica: > >> Aliased parameters are meant to cure a deficiency in e.g. containers. >> With current Ada, it's awkward to replace an element of a container. >> >> Now if you make the curser an aliased parameter, the function result >> may dereference safely the cursor, since the cursor and the result are >> tightly coupled, > > But this is already the case in Ada 2005. The lifetime of passed-in > objects extends beyond the immediate need for evaluating the > expression: > > | Leaving an execution happens immediately after its completion, > | except in the case of a _master_: the execution of a body other than > | a package_body; the execution of a statement; or the evaluation of > | an expression, function_call, or range that is not part of an > | enclosing expression, function_call, range, or simple_statement > | other than a simple_return_statement. This works in your example because you avoid the type system completely and thus the accessibility checks. It also would work if you don't care that it can raise Program_Error if someone passes in a local variable. That runtime source of failure is not acceptable, and the use of alised parameters makes it a compile-time check. Randy. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-03-28 11:47 Ada 2012 : aliased parameters ? Yannick Duchêne (Hibou57) 2011-03-28 11:56 ` Dmitry A. Kazakov 2011-03-28 11:56 ` AdaMagica @ 2011-03-29 3:16 ` Randy Brukardt 2011-03-29 7:34 ` Maciej Sobczak 2011-04-23 18:47 ` Florian Weimer 2 siblings, 2 replies; 18+ messages in thread From: Randy Brukardt @ 2011-03-29 3:16 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2314 bytes --] "Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message news:op.vs1xo8puule2fv@index.ici... ... > Quote from Ada 2012: > > Parameters can now be explicitly aliased, allowing parts of > function results to designate parameters and forcing > by-reference parameter passing. > >I'm not sure I've understood. What was wrong with access type parameters ? Two things: (1) need to explicitly write 'Access at every call site, when all you are doing is passing a by-reference parameter; (2) anonymous access requires a run-time accessibility level; that means that passing the wrong thing (a local object, for instance) might cause Program_Error to be raised later. This is an unnecessary hazard for the sorts of uses envisioned for aliased parameters. Aliased parameters move the check to the call site, where it almost always will succeed (there is one case involving function calls inside of allocators where it might fail, and if it does it almost always will fail at compile-time). > I don't see a reason why aliased parameters may be required (and don't > feel this can be clean). Well, why not in/out parameter for functions, as Ada 2012 allows "in out" parameters on functions. The usual use of aliased parameters is on an "in out" parameter. >things like test-and-set are common idioms, but I really can't figure why >this one in particular was required. The motivating case is to make the containers better. Ada 2012 adds the following to all of the containers: function Reference (Container : aliased in out Vector; Position : in Cursor) return Reference_Type; where Reference_Type is defined as: type Reference_Type (Element : not null access Element_Type) is private with Implicit_Dereference => Element; The aspect "Implicit_Dereference" lets you omit "Element.all" from uses of this type, so the call: My_Vector.Reference (My_Cursor).Comp := 10; is legal (presuming the element type has a component "Comp"). And another "feature" allows a form of user-defined indexing, so you actually can write: My_Vector (My_Cursor).Comp := 10; which is a big improvement over using Update_Element (which requires writing a procedure to do an in-place element update). Randy. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-03-29 3:16 ` Randy Brukardt @ 2011-03-29 7:34 ` Maciej Sobczak 2011-03-30 0:09 ` Randy Brukardt 2011-04-23 18:47 ` Florian Weimer 1 sibling, 1 reply; 18+ messages in thread From: Maciej Sobczak @ 2011-03-29 7:34 UTC (permalink / raw) On 29 Mar, 05:16, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > The motivating case is to make the containers better. Ada 2012 adds the > following to all of the containers: > > function Reference (Container : aliased in out Vector; Position : in > Cursor) > return Reference_Type; Out of curiosity - is it possible to leak the reference this way? I mean - is it possible for the caller to make a copy of returned reference and store it arbitrarily long? Note that the "copy" might not be obvious, as in: declare My_Element : Vector_Type.Reference_Type renames My_Vector.Reference (My_Cursor); begin My_Element.Comp := 10; My_Element.Other_Comp := 3.14; end; The C++ equivalent of this is both a fantastic performance feature and a deadly security hole. How is this solved in Ada? -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-03-29 7:34 ` Maciej Sobczak @ 2011-03-30 0:09 ` Randy Brukardt 2011-03-30 19:44 ` Randy Brukardt 0 siblings, 1 reply; 18+ messages in thread From: Randy Brukardt @ 2011-03-30 0:09 UTC (permalink / raw) "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message news:f0c752a7-993e-4cee-addc-ff748a1fe10d@f18g2000yqd.googlegroups.com... On 29 Mar, 05:16, "Randy Brukardt" <ra...@rrsoftware.com> wrote: >> The motivating case is to make the containers better. Ada 2012 adds the >> following to all of the containers: >> >> function Reference (Container : aliased in out Vector; Position : in >> Cursor) >> return Reference_Type; >Out of curiosity - is it possible to leak the reference this way? I >mean - is it possible for the caller to make a copy of returned >reference and store it arbitrarily long? No, because the attempt to make the copy will fail the accessibility check. Specifically, the access discriminant has the lifetime of the containing object. So if the object is short-lived (as most return objects are), the access discriminant cannot be assigned into anything that lives longer. OTOH, if the object is long-lived, there is no problem, because as long as the object lives, attempting to add or remove elements from the container is not allowed and must raise Program_Error. There is are a couple of small holes that occur by using Unchecked_Deallocation, but no one is going to do that by accident, and if there is any sort of management (or sense) on a project, the end-around will be easily detected. >Note that the "copy" might not be obvious, as in: > >declare > My_Element : Vector_Type.Reference_Type renames > My_Vector.Reference (My_Cursor); >begin > My_Element.Comp := 10; > My_Element.Other_Comp := 3.14; >end; This isn't a leak, because the Reference object has to continue to exist until the renames goes away (and thus the reference). Instead, My_Vector is locked against "tampering" so long as that object exists. So any attempt to delete this element in this block body will raise Program_Error. >The C++ equivalent of this is both a fantastic performance feature and >a deadly security hole. How is this solved in Ada? See above. Randy. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-03-30 0:09 ` Randy Brukardt @ 2011-03-30 19:44 ` Randy Brukardt 0 siblings, 0 replies; 18+ messages in thread From: Randy Brukardt @ 2011-03-30 19:44 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:imtscf$c6u$1@munin.nbi.dk... ... > There is are a couple of small holes that occur by using > Unchecked_Deallocation, but no one is going to do that by accident, and if > there is any sort of management (or sense) on a project, the end-around > will be easily detected. I should mention that there is a relatively easy way to defeat these accessibility checks: simply use .all'Unchecked_Access. More generally, any unchecked programming can of course default the protection. Nothing new about that - that's true of any Ada construct. But of course it is obvious that unchecked programming is being used, so again that is a management problem. Randy. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-03-29 3:16 ` Randy Brukardt 2011-03-29 7:34 ` Maciej Sobczak @ 2011-04-23 18:47 ` Florian Weimer 2011-04-25 7:19 ` Randy Brukardt 1 sibling, 1 reply; 18+ messages in thread From: Florian Weimer @ 2011-04-23 18:47 UTC (permalink / raw) * Randy Brukardt: > The motivating case is to make the containers better. Ada 2012 adds the > following to all of the containers: > > function Reference (Container : aliased in out Vector; Position : in > Cursor) > return Reference_Type; > > where Reference_Type is defined as: > > type Reference_Type (Element : not null access Element_Type) is private > with > Implicit_Dereference => Element; Is it necessary that Element is a discriminant? If the aliased business works with fields, you could write something like this: type String_Reference is record Data : access String; end record; function "+" (S: aliased String) return String_Reference is begin return String_Reference'(Data => S'Access); end "+"; String_Reference could be part of an array, so we would get ragged arrays as a side effect. In any case, it seems to me that the definition of "master" in 7.6.1 needs updating. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-04-23 18:47 ` Florian Weimer @ 2011-04-25 7:19 ` Randy Brukardt 2011-04-28 19:47 ` Florian Weimer 0 siblings, 1 reply; 18+ messages in thread From: Randy Brukardt @ 2011-04-25 7:19 UTC (permalink / raw) "Florian Weimer" <fw@deneb.enyo.de> wrote in message news:87aafgerez.fsf@mid.deneb.enyo.de... >* Randy Brukardt: > >> The motivating case is to make the containers better. Ada 2012 adds the >> following to all of the containers: >> >> function Reference (Container : aliased in out Vector; Position : in >> Cursor) >> return Reference_Type; >> >> where Reference_Type is defined as: >> >> type Reference_Type (Element : not null access Element_Type) is >> private >> with >> Implicit_Dereference => Element; > > Is it necessary that Element is a discriminant? Yes, because access discriminants have special accessibility rules which happen to have the right effect. > If the aliased business works with fields, you could write something like > this: > > type String_Reference is record > Data : access String; > end record; You can write this, but you lose all accessibility checking if you do. The accessibility of a normal component is that of the type, which is typically library level. OTOH, a discriminant in a returned object has the accessibility of the point of call; combined with the rules for aliased parameters, such a discriminant will always succeed (no runtime checks or overhead needed) and will always be safe (can't copy it into anything with a longer lifetime, which is essentially anything). I'm no fan of accessibility checks, but in this case at least they don't get in the way beyond preventing operations that we don't want to allow in the first place. >In any case, it seems to me that the definition of "master" in 7.6.1 needs >updating. It did, but only for bugs. The access discriminant semantics is from Ada 95, although it was never defined properly (probably still isn't, although not for the lack to trying). We've just found a good use for the strange semantics. Randy. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-04-25 7:19 ` Randy Brukardt @ 2011-04-28 19:47 ` Florian Weimer 2011-04-28 23:54 ` Randy Brukardt 0 siblings, 1 reply; 18+ messages in thread From: Florian Weimer @ 2011-04-28 19:47 UTC (permalink / raw) * Randy Brukardt: >> Is it necessary that Element is a discriminant? > > Yes, because access discriminants have special accessibility rules which > happen to have the right effect. This is unfortunate because it means that this cannot be used to make variadic argument list trick safer and less of a hack. > It did, but only for bugs. The access discriminant semantics is from Ada 95, > although it was never defined properly (probably still isn't, although not > for the lack to trying). We've just found a good use for the strange > semantics. I don't think the difference is observable in Ada 95 because you couldn't return new objects of limited type. By the way, how tight are the access level checks? Is it relatively safe to assume that if an Ada 2005 compiler compiles a program which makes heavy use of anonymous access types and runs it without exceptions, then there are no dangling pointers? (Ignoring unchecked deallocation, of course.) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-04-28 19:47 ` Florian Weimer @ 2011-04-28 23:54 ` Randy Brukardt 2011-04-30 18:32 ` Florian Weimer 0 siblings, 1 reply; 18+ messages in thread From: Randy Brukardt @ 2011-04-28 23:54 UTC (permalink / raw) "Florian Weimer" <fw@deneb.enyo.de> wrote in message news:87mxjaf99i.fsf@mid.deneb.enyo.de... >* Randy Brukardt: > >>> Is it necessary that Element is a discriminant? >> >> Yes, because access discriminants have special accessibility rules which >> happen to have the right effect. > > This is unfortunate because it means that this cannot be used to make > variadic argument list trick safer and less of a hack. One could argue that variadic arguments are themselves a hack. :-) This feature is intended for one particular use (and any other uses are a happy accident): providing safe user-defined dereferencing. What is needed for it to be safe is to prevent any copying of the access value while still allowing it to be dereferenced (including assigning into it). We originally had some syntax to define the accessibility of the returned access type, but it was eventually pointed out that access discriminants already had the appropriate accessibility. (Anonymous access return types also have this same accessibility.) Thus we changed the mechanism to use the discriminants rather than inventing a new feature. The advantage of the aliased parameters is that they eliminate the runtime checks by forcing the checks to the call site (where they can be statically made 99% of the time). >> It did, but only for bugs. The access discriminant semantics is from Ada >> 95, >> although it was never defined properly (probably still isn't, although >> not >> for the lack to trying). We've just found a good use for the strange >> semantics. > > I don't think the difference is observable in Ada 95 because you > couldn't return new objects of limited type. Could be. > By the way, how tight are the access level checks? Is it relatively > safe to assume that if an Ada 2005 compiler compiles a program which > makes heavy use of anonymous access types and runs it without > exceptions, then there are no dangling pointers? (Ignoring unchecked > deallocation, of course.) The intent is that it is impossible to create a dangling pointer if no unchecked programming is used. (Unchecked_Deallocation, 'Unchecked_Access, Unchecked_Conversion, Address_to_Access_Conversions, abuse of Unchecked_Unions, etc.) That goes for all access types (not just anonymous ones). The problem, of course, is that it is impractical to do much without using one of those things. (I've only succeeded in using 'Access once in one of my programs; in all other cases I had to use 'Unchecked_Access.) We're constantly fixing holes in the model, and it is easy to use the unchecked things, so I wouldn't consider it impossible to get a dangling pointer. (Personally, I prefer to hide pointers as much as possible, as in the container cursors, so that dangling pointer detection becomes much more possible, and their creation becomes less likely.) Randy. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-04-28 23:54 ` Randy Brukardt @ 2011-04-30 18:32 ` Florian Weimer 2011-04-30 23:46 ` Randy Brukardt 0 siblings, 1 reply; 18+ messages in thread From: Florian Weimer @ 2011-04-30 18:32 UTC (permalink / raw) * Randy Brukardt: >> This is unfortunate because it means that this cannot be used to make >> variadic argument list trick safer and less of a hack. > > One could argue that variadic arguments are themselves a hack. :-) It would make it possible to call this little gem, PostgreSQL's main client function for executing SQL statements, PGresult *PQexecParams(PGconn *conn, const char *command, int nParams, const Oid *paramTypes, const char * const *paramValues, const int *paramLengths, const int *paramFormats, int resultFormat); without any allocations and in a type-safe manner (for a predefined set of types). For such untyped external interfaces, varidic subprograms are often handy. > The advantage of the aliased parameters is that they eliminate the runtime > checks by forcing the checks to the call site (where they can be statically > made 99% of the time). I'm wondering if it is necessary that the returned limited record is controlled, so that a reference counter can be incremented and later decremented to ensure that the access discriminant does not become dangling. That would make the whole thing a bit clumsy to use, and come with quite a bit of run-time overhead. > The intent is that it is impossible to create a dangling pointer if no > unchecked programming is used. (Unchecked_Deallocation, 'Unchecked_Access, > Unchecked_Conversion, Address_to_Access_Conversions, abuse of > Unchecked_Unions, etc.) That goes for all access types (not just anonymous > ones). The problem, of course, is that it is impractical to do much without > using one of those things. (I've only succeeded in using 'Access once in one > of my programs; in all other cases I had to use 'Unchecked_Access.) Anonymous access types seem to help quite a bit. I use 'Access for access discriminants, creating proxies, to fake the in-out parameter mode for functions, and on locally defined callback functions. > (Personally, I prefer to hide pointers as much as possible, as in > the container cursors, so that dangling pointer detection becomes > much more possible, and their creation becomes less likely.) And implicit deference could make them even safer to use. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ada 2012 : aliased parameters ? 2011-04-30 18:32 ` Florian Weimer @ 2011-04-30 23:46 ` Randy Brukardt 0 siblings, 0 replies; 18+ messages in thread From: Randy Brukardt @ 2011-04-30 23:46 UTC (permalink / raw) "Florian Weimer" <fw@deneb.enyo.de> wrote in message news:87y62ra8uz.fsf@mid.deneb.enyo.de... ... >> The advantage of the aliased parameters is that they eliminate the >> runtime >> checks by forcing the checks to the call site (where they can be >> statically >> made 99% of the time). > > I'm wondering if it is necessary that the returned limited record is > controlled, so that a reference counter can be incremented and later > decremented to ensure that the access discriminant does not become > dangling. That would make the whole thing a bit clumsy to use, and > come with quite a bit of run-time overhead. It's not required, but that is the way it will be used in the containers (so that the tampering check can apply only so long as the access exists). One hopes that compilers will work to minimize the overhead in this case (the non-list finalization implementation that GNAT is supposedly getting will be ideal for such cases). >> The intent is that it is impossible to create a dangling pointer if no >> unchecked programming is used. (Unchecked_Deallocation, >> 'Unchecked_Access, >> Unchecked_Conversion, Address_to_Access_Conversions, abuse of >> Unchecked_Unions, etc.) That goes for all access types (not just >> anonymous >> ones). The problem, of course, is that it is impractical to do much >> without >> using one of those things. (I've only succeeded in using 'Access once in >> one >> of my programs; in all other cases I had to use 'Unchecked_Access.) > > Anonymous access types seem to help quite a bit. I use 'Access for > access discriminants, creating proxies, to fake the in-out parameter > mode for functions, and on locally defined callback functions. Well, of course for "in out", just use that if you are using Ada 2012 -- no need to fake it. The other uses of course will remain. >> (Personally, I prefer to hide pointers as much as possible, as in >> the container cursors, so that dangling pointer detection becomes >> much more possible, and their creation becomes less likely.) > > And implicit deference could make them even safer to use. Exactly. And more convinient, too. I would like to see containers use to be as easy as using access types; if that is true, then there is little reason to use the less safe access types to create lists and trees (and maps and sets). There always will be cases not covered by containers or where performance needs are ultra-critical -- but those should be the unusual cases. Ada 2012 definitely moves us closer to that goal. Randy. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-04-30 23:46 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-03-28 11:47 Ada 2012 : aliased parameters ? Yannick Duchêne (Hibou57) 2011-03-28 11:56 ` Dmitry A. Kazakov 2011-03-29 3:04 ` Randy Brukardt 2011-03-28 11:56 ` AdaMagica 2011-03-29 18:22 ` Florian Weimer 2011-03-29 18:34 ` Shark8 2011-03-29 19:35 ` Florian Weimer 2011-03-30 0:12 ` Randy Brukardt 2011-03-29 3:16 ` Randy Brukardt 2011-03-29 7:34 ` Maciej Sobczak 2011-03-30 0:09 ` Randy Brukardt 2011-03-30 19:44 ` Randy Brukardt 2011-04-23 18:47 ` Florian Weimer 2011-04-25 7:19 ` Randy Brukardt 2011-04-28 19:47 ` Florian Weimer 2011-04-28 23:54 ` Randy Brukardt 2011-04-30 18:32 ` Florian Weimer 2011-04-30 23:46 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox