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,6339fea48a1b8cda,start
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!news.mixmin.net!news2.arglkargh.de!noris.net!nntp.ilk.net!not-for-mail
From: Markus Schoepflin <nospam@no.spam>
Newsgroups: comp.lang.ada
Subject: Enumeration representation clause surprise.
Date: Wed, 11 Jun 2008 13:38:17 +0200
Organization: Customer of ILK Internet GmbH, Karlsruhe, Germany
Message-ID: <g2odf9$3um$1@nntp.ilk.net>
NNTP-Posting-Host: csdc.comsoft.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: nntp.ilk.net 1213184297 4054 212.86.205.70 (11 Jun 2008 11:38:17 GMT)
X-Complaints-To: usenet@ilk.net
NNTP-Posting-Date: Wed, 11 Jun 2008 11:38:17 +0000 (UTC)
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
Xref: g2news1.google.com comp.lang.ada:642
Date: 2008-06-11T13:38:17+02:00
List-Id: <comp.lang.ada>

Hello,

please consider the following code snippet:

    type ENUM_T is (ONE, TWO);
    for ENUM_T use (ONE => 1, TWO => 2);

    type RECORD_T is record
       A1 : ENUM_T;
       A2 : ENUM_T;
    end record;
    for RECORD_T use record
       A1 at 0 range 0 .. 0; -- (*)
       A2 at 1 range 0 .. 7;
    end record;
    for RECORD_T'Size use 2 * 8;

    FOO : RECORD_T;

I was _very_ surprised to discover that when executing

    FOO.A1 := TWO;
    FOO.A2 := TWO;

the binary content of FOO looks like this:

    00000010 00000001

IOW, for A1 ONE is coded as 0 and TWO as 1, and for A2 ONE is coded as 1 
and TWO as 2.

I checked this with GNAT 3.4.5 and some old DEC Ada compiler, therefore I 
think this behaviour is compiler independent.

Anybody knows why the compiler is allowed to silently ignore my 
representation clause for the enumeration? I would have expected to get an 
error at the indicated line, telling me that A1 is too small.

BTW, this was found in a real word application, where code like this was 
used to model a given external interface, and later the enumeration was 
extended by a few values, but the record representation clause was never 
updated.

Is there a way I can protect myself from this very nasty trap?

Best regards,
Markus