From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,d23826ff0acb491b X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news1.google.com!postnews.google.com!d9g2000prh.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Gem 39 - compiler specific? Date: Thu, 3 Sep 2009 08:26:50 -0700 (PDT) Organization: http://groups.google.com Message-ID: <4bff103b-1797-4e2b-9dcf-7466b667c59b@d9g2000prh.googlegroups.com> References: <9e0bbbcd-260f-48ed-8043-d6280c633e85@h3g2000yqa.googlegroups.com> <19268dbw82hf4.aii8as09aapk.dlg@40tude.net> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1251991610 10075 127.0.0.1 (3 Sep 2009 15:26:50 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 3 Sep 2009 15:26:50 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: d9g2000prh.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:8129 Date: 2009-09-03T08:26:50-07:00 List-Id: On Sep 3, 12:26=A0am, "Dmitry A. Kazakov" wrote: > On Wed, 2 Sep 2009 18:20:36 -0500, Randy Brukardt wrote: > > "Maciej Sobczak" wrote in message > >news:9e0bbbcd-260f-48ed-8043-d6280c633e85@h3g2000yqa.googlegroups.com... > >> Consider: > > >>http://www.adacore.com/2008/06/09/gem-39/ > > >> The example code performs Unchecked_Conversion between addresses of > >> two different array types. > >> As far as I understand, there is no standard provision for arrays to > >> occupy contiguous memory space (and not even for the alignment of > >> their components) and such a conversion relies heavily on the > >> assumption that arrays can be "overlaid" by plain address > >> reinterpretation. > > >> Still, this technique is quite attractive. What is the chance (in > >> practice) to hit the compiler that does not get it "right"? > > > This is horrible code; it should never be written in Ada 95 or newer! T= he > > problem is that System.Address is not necessarily the same as a general > > access type, so this Unchecked_Conversion may not work (or may not even > > compile) on another implementation. (It won't on at least some versions= of > > Janus/Ada, for instance.) > > > Ada 95 provides System.Address_to_Access_Conversions for this purpose, = so at > > the very least the writer of the Rock (it surely isn't a "Gem"!!!) shou= ld > > have used it: > > > procedure Write_Buffer > > =A0 =A0 =A0 (Stream : not null access Ada.Streams.Root_Stream_Type'Clas= s; > > =A0 =A0 =A0 =A0Item =A0 : in Buffer) =A0is > > =A0 =A0 =A0 Item_Size : constant Stream_Element_Offset :=3D > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Buffer'Object_Size / Stream_= Element'Size; > > > =A0 =A0 =A0subtype SEA is Stream_Element_Array (1..Item_Size); > > > =A0 =A0 =A0package A2A is new System.Address_to_Access_Conversions (SEA= ); > > > begin > > =A0 =A0 =A0 Ada.Streams.Write (Stream.all, A2A.To_Pointer (Item'Address= ).all); > > end Write_Buffer; > > > (As an aside, this technique could not work in Janus/Ada if Buffer was = an > > unconstrained array: 'Address of an unconstrained array points at the a= rray > > descriptor, not the data. > > It must point to the first array element 13.3(14). BTW, it is interesting > where it should point when the array is empty. > > > (That's in fact true for all objects in Janus/Ada: > > there is a static part and an optional dynamic part, and all operations= like > > 'Address and 'Size point at the static part. That was decided long befo= re > > Ada 95 came around and tried to change these definitions; it's not prac= tical > > to change in Janus/Ada as address clauses could not be made to work - a= mong > > other things - if the static part is ignored.) > > Skewed address is not a problem here. The problem is that > System.Address_To_Access_Conversions should take an access type as a > parameter rather than declare it new. This makes its use quite limited. I don't see any limitation, at least where To_Pointer is concerned (which is what the above code needed to use). If you declare an instance of this package for any object type T: type Convert_T_Access is new System.Address_To_Access_Conversions (T); then an object of type Convert_T_Access.Object_Pointer can be converted to any access type whose designated type is T. I checked through the legality rules in 4.6, and I couldn't find a way to declare an access-to-T type that you couldn't convert an Object_Pointer to. Thus, if you have any access type type Acc_T is access T; [or access all T, or access constant T] you can convert an address Addr to an Acc_T by saying: Acc_T (Convert_T_Access.To_Pointer (Addr)) There do seem to be some limitations on using To_Address, though; you can't convert an "access constant T" to an Object_Pointer, and you can't convert an access-to-T type that is nested inside a subprogram. So you couldn't use To_Address on those types. Offhand, though, I'd guess that there is much less need for this than for To_Pointer, so this may not be a severe enough limitation to require fixing. -- Adam