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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7b60a2e8329f4e64,start X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.68.202.68 with SMTP id kg4mr15129919pbc.3.1358185431543; Mon, 14 Jan 2013 09:43:51 -0800 (PST) Received: by 10.50.33.171 with SMTP id s11mr2204753igi.13.1358185431499; Mon, 14 Jan 2013 09:43:51 -0800 (PST) Path: s9ni106366pbb.0!nntp.google.com!f6no12681709pbd.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 14 Jan 2013 09:43:51 -0800 (PST) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=192.31.106.36; posting-account=YkFdLgoAAADpWnfCBA6ZXMWTz2zHNd0j NNTP-Posting-Host: 192.31.106.36 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com> Subject: GNAT 4.4.5 Record Bit_Order Endian issues From: awdorrin Injection-Date: Mon, 14 Jan 2013 17:43:51 +0000 Content-Type: text/plain; charset=ISO-8859-1 Date: 2013-01-14T09:43:51-08:00 List-Id: I have a record with specification definition that starts, using big endian notation, with: for TRACK_RECORD_TYPE use record TRACK_ID at 0 range 0 .. 11; TRACK_ID_CNT at 1 range 4 .. 9; ... The meaning being that the first 12 bits hold a track id and the next 6 bits hold the Count value. I have had success in the past, using the gnat 4.4.5 compiler under Debian 6.0.6, to use the directive: for TRACK_RECORD_TYPE'Bit_Order use System.High_Order_First; In order to continue using the definition in the big endian notation. >From the build output, the Bit_Order flag at first appears to be processed correctly, with the built compiler flags displaying to translated little endian definition as: for TRACK_RECORD_TYPE use record TRACK_ID at 0 range 4 .. 15; TRACK_ID_CNT at 1 range 11 .. 6; ... 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 Using the following code: TRK_REC.TRACK_ID := 1; Text_IO.Put_Line("A: TRK_REC.TRACK_ID = " & Int32'Image(TRK_REC.TRACK_ID)); TRK_REC.TRACK_ID_CNT := 1; Text_IO.Put_Line("B: TRK_REC.TRACK_ID = " & Int32'Image(TRK_REC.TRACK_ID)); The output displayed is: A: TRK_REC.TRACK_ID = 1 B: TRK_REC.TRACK_ID = 1025 Apparently because the TRACK_ID field is being read as a 16-bit value where: "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 to the improper definition translation. Not sure if this 'bug' would be fixed in a newer version of the GNAT compiler or not.