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!postnews.google.com!13g2000prl.googlegroups.com!not-for-mail
From: Adam Beneschan <adam@irvine.com>
Newsgroups: comp.lang.ada
Subject: Re: Gem 39 - compiler specific?
Date: Wed, 2 Sep 2009 17:12:20 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: <40f0d9bb-8d7f-46d1-9397-5b7570d1cd0b@13g2000prl.googlegroups.com>
References: <9e0bbbcd-260f-48ed-8043-d6280c633e85@h3g2000yqa.googlegroups.com>
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 1251936742 13319 127.0.0.1 (3 Sep 2009 00:12:22
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Thu, 3 Sep 2009 00:12:22 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: 13g2000prl.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:8118
Date: 2009-09-02T17:12:20-07:00
List-Id: <comp.lang.ada>

On Sep 2, 1:38=A0pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> 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"?

There are a number of portability problems with this gem ("uncut
gem"?).  All are mentioned or hinted at in the comments section of the
page you reference.

(1) It uses 'Object_Size which is not defined by the Ada language.

(2) It uses Unchecked_Conversion to convert between System.Address and
an access type.  As mentioned both in the comments and in Randy's
post, this is sloppy and really ought to use
System.Access_To_Address_Conversions (or, better, use
Unchecked_Conversion on the entire array as Randy also suggested).

(3) In the definition of Buffer:

    type Buffer is array (1..32) of Interfaces.Unsigned_16;

there is no guarantee that there won't be gaps between elements of the
array, which would screw the whole thing up.  (This is unlikely for a
byte-addressable machine, perhaps, but not all machines are like that;
Irvine Compiler's Ada compiler supports a target whose
System.Storage_Unit is 32, and on that machine, the compiler would put
each array element in a separate 32-bit word unless other
representation clauses tell it not to.)

I think it's necessary to add:

    for Buffer'Component_Size use 16;
    pragma Pack (Buffer);

to ensure that each array element takes up exactly 16 bits and there
are no extra gaps.  (If the Implementation Advice is followed (13.3
(71-73)), the compiler should reject the program if it cannot support
this, as might be the case on a machine with a 36-bit word; but that's
a darn sight better than accepting the program and letting it not work
right.)  I'm not 100% clear on whether the Pack is necessary.

With all those issues, I'd say this gem needs a bit of grinding.

                                      -- Adam