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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,f7c38a023cf370dc
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!postnews.google.com!a10g2000yqn.googlegroups.com!not-for-mail
From: okellogg <okellogg@users.sourceforge.net>
Newsgroups: comp.lang.ada
Subject: Re: Should representation clauses be complete for each bit?
Date: Wed, 20 Jul 2011 08:29:18 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: 
 <17c212b1-d0a6-498a-a381-71188a67ec65@a10g2000yqn.googlegroups.com>
References: 
 <73c10395-ec4f-4a02-b0fc-e35bc14424fa@e18g2000vbx.googlegroups.com>
 <wcczkk9ngxy.fsf@shell01.TheWorld.com>
NNTP-Posting-Host: 80.156.46.211
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Trace: posting.google.com 1311176137 17951 127.0.0.1 (20 Jul 2011 15:35:37
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Wed, 20 Jul 2011 15:35:37 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: a10g2000yqn.googlegroups.com; posting-host=80.156.46.211;
 posting-account=a23u_AkAAAB-Xz81hSqodYsmJRrMwioK
User-Agent: G2/1.0
X-HTTP-Via: 1.1 GSM7272, 1.1 GSM7273, 1.1 GSW7281
X-Google-Web-Client: true
X-Google-Header-Order: VCRUHALNK
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
 Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729;
 .NET4.0C; .NET4.0E),gzip(gfe)
Xref: g2news1.google.com comp.lang.ada:20239
Date: 2011-07-20T08:29:18-07:00
List-Id: <comp.lang.ada>

On 20 Jul., 16:51, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> [...]
> > IMHO it would be a real gain if we could explicitly mention the unused
> > bits in the rep spec.
>
> I think the unused bits should be explicitly declared.

My use case originates from a bit packed communication protocol where
the standard requires spare bits interspersed among the useful data.
However the API of the driver shall not expose these spare fields.
This leads to the complexity that I have two sets of type definitions,
one for on-the-wire usage and the other, almost identical (modulo the
spare fields) for the driver API - which entails the need for hand
coded conversion between these types.

Oliver