Re: Gem 39 - compiler specific?

[Adam Beneschan <adam@irvine.com>]

On Sep 2, 1:38 pm, 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