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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,2ceb82769e7e23b
X-Google-Attributes: gid103376,public
From: Niklas Holsti <nholsti@icon.fi>
Subject: Re: Help needed in port to GNAT95 from verdix
Date: 1998/05/15
Message-ID: <355B6246.457F7282@icon.fi>#1/1
X-Deja-AN: 353326958
Content-Transfer-Encoding: 7bit
References: <6jcvoc$drd$1@plug.news.pipex.net>
Content-Type: text/plain; charset=us-ascii
Organization: Telecom Finland News Service
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1998-05-15T00:00:00+00:00
List-Id: <comp.lang.ada>


Paul Hussein wrote:
> 
> I do not understand  why a piece of code that works on verdix will not now
> work an gnat95, and this is an important piece of code. If anyone could help
> it would be most appreciated.
> 
> When I run this code sample, and the code itself  in our system I get a
> constraint error.
> This code endeavours to turn any type into an array of floats for passing
> over the network.

Using floats here is quite surprising, but perhaps you know what you
are doing... I would have used storage_units. Also, you might want to
check out the Ada 95 stream concept, with the 'Read and 'Write
services.

[ elided package spec ]

> with UNCHECKED_CONVERSION;
> package body Packer is
>    --
>    -- PURPOSE:
>    -- Packs the object into the array of floats
>    --
>    function Pack ( Object : in Object_Type ) return Packed_Object_Type is
>       Size_Of_Array : POSITIVE := Object_Type'size/FLOAT'size + 1;
>       subtype Local_Packed_Object_Type is Packed_Object_Type ( 1 ..
> Size_Of_Array );
>       Packed_Object : Local_Packed_Object_Type;
>       function To_Array is new UNCHECKED_CONVERSION
>         ( Source => Object_Type,
>           Target => Local_Packed_Object_Type );

It seems quite likely that the exact size of the Source and Target
types will differ. Unchecked conversion between types of different
sizes is IMHO rather risky, from a portability point of view.
Same comment for the unchecked conversion in Packer.UnPack.

[ elided rest of Packer ]

> with Packer;
> with Text_IO;
> with Sim_Support;
> procedure Test is
 
[ elided a bit ]

>    package p is new packer ( blob );
>    procedure pack
>       ( Data   : in blob;
>         Floats : out Sim_Support.Data_Array ) is
>    begin
>       declare
>          Packed : constant P.Packed_Object_Type :=
>             P.Pack ( data );
>       begin
>          Floats := Sim_Support.Data_Array ( Packed );

According to my trial run, this tries to assign an array of
length 52 to an array of length 10000. Constraint error
is to be expected.

I cannot imagine how you got this to work under Verdix, except
by turning off constraint checks. The length of the Packed array
may have been different, due to a different lay-out of the "blob"
type under Verdix and GNAT, but the length must surely have been
less than 10000.

Do check out the streams and 'Read, 'Write. I think they are what
you need here.