Re: Overlay allowability

[Tucker Taft <stt@averstar.com>]

"Marc A. Criley" wrote:
> 
> A few times in my career I've encountered situations where two different
> representations of the same set of bits are desired in a high
> performance application, and this has been effected with the aid of the
> 'Address representation attribute.  In Ada 95, an example of this would
> be:
> 
>   N : Natural;
> 
>   SN : Stream_Element_Array(1..N'Size / System.Storage_Unit);
>   for SN'Address use N;

I presume you meant:  for SN'Address use N'Address.

Also, N'Size/System.Storage_Unit is not what you want, probably.  
More likely is:
    (N'Size + System.Storage_Unit - 1)/System.Storage_Unit

I.e., round the division up.

N'Size is probably going to be 31 on your typical 32-bit computer.
    
> 
> This has always struck me as somewhat iffy, but I confess I've used
> it as well on a couple occasions with Ada 83.  I've always found that
> it works as one intuitively expects, so long as all alignment, layout
> and sizing aspects are fully thought through and accommodated.
> 
> So, is this within the definition of Ada 95?  Or is it well-defined
> only for certain constructs, say scalars and non-tagged types, and
> dicey for others?  Are there type constructs for which relying on it
> is clearly a reliance on undefined behavior, is the whole construct a
> reliance on undefined behavior?  Is there a de facto, in place of a
> formal, expectation that this should work as expected?

This is well-defined in Ada 95, though as mentioned elsewhere, using unchecked
conversion is more explicit and probably less likely to run into
problems.  As far as the Ada 95 RM, using 'Address for overlaying is
safer than in Ada 83, because of RM95 13.3(19):

   If the Address of an object is specified ... then the implementation
   should not perform optimizations based on assumptions of no aliases.

Note that this is implementation advice, not an implementation requirement.
The probable reason it is advice rather than requirement is because of
the difficulty of formulating this recommendation exactly and testably.

> Marc A. Criley

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA