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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c70bb16b3813e0fd
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-11-20 21:06:37 PST
Path: 
 nntp.gmd.de!xlink.net!news.fhg.de!berlin.fhg.de!isst.fhg.de!hahn.informatik.hu-berlin.de!zib-berlin.de!prise.nz.dlr.de!news.dfn.de!swiss.ans.net!howland.reston.ans.net!pipex!sunic!news.funet.fi!hydra.Helsinki.FI!holsti
From: holsti@cs.Helsinki.FI (Niklas Holsti)
Newsgroups: comp.lang.ada
Subject: Re: Ada Portability... NOT!
Date: 21 Nov 1994 05:06:37 GMT
Organization: University of Helsinki, Department of Computer Science
Distribution: world
Message-ID: <3ap9st$1mv@hydra.Helsinki.FI>
References: <199411182104.PAA04854@mail.cs.utexas.edu>
NNTP-Posting-Host: kypros.helsinki.fi
Date: 1994-11-21T05:06:37+00:00
List-Id: <comp.lang.ada>

In <199411182104.PAA04854@mail.cs.utexas.edu>
britt@molokai.46tg.af.mil (Capt. Britt Snodgrass) writes:

>One recent post contained what I considered an overstatement of the
>portability of Ada programs.  Let me describe my current problem and
>hopefully many of you will provide some insight into the root cause.

I have reordered the following snippets of the error report.
It seems there are two record types called ICD_IRG_010_Channel_Type
and ICD_IRG_Corrected_Input_Type. The latter has several components
of the former type:

>      Channel1 : ICD_IRG_010_Channel_Type;
>      Channel2 : ICD_IRG_010_Channel_Type;
       ...

There is a record representation clause specifying the byte locations
of the components:

>   for ICD_IRG_010_Corrected_Input_Type use
>      record at mod 8;
>      tBlock   at    0 range 0..63;
>      tMeasU20 at    8 range 0..63;
>      tOffsetU at   16 range 0..63;
>      Channel1 at   24 range 0..367;
>      Channel2 at   70 range 0..367;                    -- line 103
       ...

The compiler complains that Channel2 (and some later components)
must be 8-byte aligned:

>ERROR MESSAGES:
>*********************************  gps_io_.a  ***********************

> 103:      Channel2 at   70 range 0..367;
>A ---------^
>A:error: Appendix F: component must be aligned on a 8 byte boundary

I would guess, without being able to test my guess, that the problem
is the alignment specified for the smaller record type:

>   for ICD_IRG_010_Channel_Type use record at mod 8;

This is in contradiction with the byte position (70) specified for
Channel2 within the (8-byte aligned) larger record.  Apparently the
compiler on the former system lets a record rep spec override an
alignment specified for the component types, but the present compiler
does not let you do that. 

Try removing the "at mod 8" for ICD_IRG_010_Channel_Type.  It is not
needed for the code shown in the message, but may, of course, be needed
elsewhere in the program.  If so, I guess you could derive a "new" type
from it, and put a "mod 8" on that. 

>================================================================
>Capt Britt Snodgrass           e-mail: britt@molokai.46tg.af.mil
>                               member: Team Ada & Team OS/2
>================================================================

Hope this helps,
- Niklas Holsti


--
Niklas Holsti                         
  Until 31 Oct 1994 at Department of Computer Science, phone +358 0 708 4423
    P.O. Box 26 (Teollisuuskatu 23), FIN-00014 University of Helsinki, Finland
  From 1 Nov 1994 at Space Systems Finland Ltd, phone +358 0 4354 3928