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=-0.3 required=5.0 tests=BAYES_00,HK_RANDOM_FROM,
	INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,cef1e23795181e0c
X-Google-Attributes: gid103376,public
From: cjrgreen@concentric.net (Christopher Green)
Subject: Re: Alternate to Unchecked_Conversion - Portable?
Date: 1999/02/22
Message-ID: <36d2638e.6427631@nntp.concentric.net>#1/1
X-Deja-AN: 447390281
References: <36d05e39.0@news.pacifier.com>
Organization: Concentric Internet Services
Newsgroups: comp.lang.ada
Date: 1999-02-22T00:00:00+00:00
List-Id: <comp.lang.ada>

On Sun, 21 Feb 1999 11:33:54 -0800, "Steve Doiel"
<nospam_steved@pacifier.com> wrote:

>I discovered a technique for performing a similar function to
>Unchecked_Conversion.  Locating two data structures at the same address by
>defining the first normally and then using an address clause to locate the
>second at the same address as the first (as shown in the following sample):
>
>
>WITH Ada.Text_Io;
>WITH Interfaces;
> USE Interfaces;
>PROCEDURE TestAlias IS
>  PACKAGE Text_Io RENAMES Ada.Text_Io;
>
>  TYPE aRec IS
>    RECORD
>      f1 : Integer_32;
>      f2 : Integer_32;
>    END RECORD;
>
>  TYPE Integer_16_Array IS ARRAY( Positive RANGE <> ) OF Integer_16;
>
>  v1 : aRec;
>  v2 : Integer_16_Array( 1..4 );
>  FOR v2'ADDRESS USE v1'ADDRESS;    -- This causes v1 and v2 to occupy the
>same memory
>
>BEGIN
>  v1.f1 := 1;
>  v1.f2 := 2;
>  FOR ii IN v2'RANGE LOOP
>    Text_Io.Put( Integer_16'IMAGE( v2( ii ) ) );
>  END LOOP;
>  Text_Io.New_Line;
>END TestAlias;
>
>
>My question is: is this portable?
>
>I expect that record layouts will be dependent on different endian machines,
>and I know that this technique is inherently unsafe, but it makes things
>very simple.
>
>SteveD
>
>

It is primarily useful in situations in which alternative
implementations end up causing a bitwise copy.  If
the object to be converted is large, or the conversion
must be done many times, this can be a win.

Other than problems with data representation mis-
matches, a source of significant portability problems
is default initializations. For example, certain compilers
will apply default initializations to arrays of derived types
of System.Address, zeroing out the contents of the
array you were trying to convert.

Unless there are overriding reasons to do otherwise;
for example, a need to preserve backward com-
patibility with Ada 83, or a big performance difference
in a particular implementation, it is safer and usually
more efficient to use packages intended for this
purpose, such as Interfaces.C.Pointers.