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,
	MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,2665a1ff754ddf6,start
X-Google-Attributes: gid103376,public
From: Andreas Schulz <accot.schulz@nord-com.net>
Subject: Representation clauses and alignment in GNAT
Date: 2000/07/21
Message-ID: <8l9v5b$k77$1@nnrp1.deja.com>#1/1
X-Deja-AN: 649168133
X-Http-Proxy: 1.0 x70.deja.com:80 (Squid/1.1.22) for client 149.243.232.3
Organization: Deja.com - Before you buy.
X-Article-Creation-Date: Fri Jul 21 16:53:07 2000 GMT
X-MyDeja-Info: XMYDJUIDaschulz
Newsgroups: comp.lang.ada
X-Http-User-Agent: Mozilla/4.7 [en] (X11; I; SunOS 5.6 sun4u)
Date: 2000-07-21T00:00:00+00:00
List-Id: <comp.lang.ada>

Trying to write some code to evaluate a binary data file in 'the Ada
way' (i.e. avoiding 'and 2#0001111110000# / 2**4), I ended up with a
hierarchy of variant records with representation clauses down to
bit level, squeezed into 32 bits. The package compiled fine with
Verdix Ada, but with GNAT I get several compilation errors
'fields of "xxx_REC" must start at storage unit boundary' for the
toplevel records. Looking closer, GNAT apparently complains when
xxx_REC is a variant record, but feels OK when xxx_REC is a plain
record.

I tried to get some more insight on this topic from the GNAT
reference manual, but all I found was 13.3(32) :
An implementation need not support specific alignments...
- Followed -

So, what's 'Followed'?
- We don't have to, so we don't ?
- We don't have to, but we do (better) ?

Andreas Schulz

--
Please excuse for using Deja - it's just to keep spam out of my real
mail


Sent via Deja.com http://www.deja.com/
Before you buy.