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,7b60a2e8329f4e64 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.72.227 with SMTP id g3mr3925589pav.31.1358215041351; Mon, 14 Jan 2013 17:57:21 -0800 (PST) X-Received: by 10.50.203.9 with SMTP id km9mr186248igc.7.1358215040942; Mon, 14 Jan 2013 17:57:20 -0800 (PST) Path: s9ni107842pbb.0!nntp.google.com!f6no13914309pbd.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 14 Jan 2013 17:57:20 -0800 (PST) In-Reply-To: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues From: Adam Beneschan Injection-Date: Tue, 15 Jan 2013 01:57:21 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2013-01-14T17:57:20-08:00 List-Id: On Monday, January 14, 2013 9:43:51 AM UTC-8, awdorrin wrote: > I have a record with specification definition that starts, using big endi= an notation, with: >=20 > for TRACK_RECORD_TYPE use > record > TRACK_ID at 0 range 0 .. 11; > TRACK_ID_CNT at 1 range 4 .. 9; > ... >=20 >=20 > The meaning being that the first 12 bits hold a track id and the next 6 b= its hold the Count value. >=20 > I have had success in the past, using the gnat 4.4.5 compiler under Debia= n 6.0.6, to use the directive: for TRACK_RECORD_TYPE'Bit_Order use System.H= igh_Order_First; >=20 > In order to continue using the definition in the big endian notation. >=20 > From the build output, the Bit_Order flag at first appears to be processe= d correctly, with the built compiler flags displaying to translated little = endian definition as: >=20 >=20 >=20 > for TRACK_RECORD_TYPE use > record > TRACK_ID at 0 range 4 .. 15; > TRACK_ID_CNT at 1 range 11 .. 6; > ... >=20 > But the TRACK_ID_CNT range does not provide the proper definition. > I believe it should be: TRACK_ID_CNT at 1 range 5 .. 0 >=20 > Using the following code: >=20 > TRK_REC.TRACK_ID :=3D 1; > Text_IO.Put_Line("A: TRK_REC.TRACK_ID =3D " & Int32'Image(TRK_REC.TRACK_I= D)); > TRK_REC.TRACK_ID_CNT :=3D 1; > Text_IO.Put_Line("B: TRK_REC.TRACK_ID =3D " & Int32'Image(TRK_REC.TRACK_I= D)); >=20 > The output displayed is: >=20 > A: TRK_REC.TRACK_ID =3D 1 > B: TRK_REC.TRACK_ID =3D 1025 >=20 > Apparently because the TRACK_ID field is being read as a 16-bit value whe= re: >=20 > "0000 0100 0000 0001" -> "BBBB CCAA AAAA AAAA" > where the 'A' bits are the TRACK_ID and the B bits are part of the TRACK_= ID_CNT field, and the 'C' bits are an overlap of the second variable, due t= o the improper definition translation. >=20 > Not sure if this 'bug' would be fixed in a newer version of the GNAT comp= iler or not. Well, it looks to me like there's definitely a bug in there, unless your re= cord is an Unchecked_Union. If the fields really do overlap, the program s= hould not compile; the language doesn't allow overlapping fields except in = variant record cases (13.5.1(11)). And if they don't overlap, then of cour= se setting one component should not affect the value of the other one. -- Adam