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,fd173879a595bde X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!newsread.com!news-xfer.newsread.com!nntp.abs.net!news.abs.net!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Default rep specs for record types - documented?? References: From: Stephen Leake Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:5bSF9r5uDMc1b2Pp9pe2kKD1qTg= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Nov 2005 09:39:42 -0500 NNTP-Posting-Host: 66.159.65.1 X-Complaints-To: abuse@toad.net X-Trace: news.abs.net 1131115194 66.159.65.1 (Fri, 04 Nov 2005 09:39:54 EST) NNTP-Posting-Date: Fri, 04 Nov 2005 09:39:54 EST Xref: g2news1.google.com comp.lang.ada:6191 Date: 2005-11-04T09:39:42-05:00 List-Id: Stephen Leake writes: > Someone mentioned a 'pragma Preserve_Layout', which presumably means > "assume a representation clause that puts things in declaration order, > with the base size for each component, and no gaps". That would be > useful, in situations where the type declarations do in fact match the > hardware precisely. Hmm. That is true for most of the rep clauses I've > written recently. I'll have to suggest that to AdaCore as a possible > enhancement; it would have prevented my bug. I've submitted the following to AdaCore: I had a record: record_byte_length : constant := 4; type Record_Type is record field_1 : Integer_16; field_2 : Integer_16; end record; for record_type use record Field_1 at 0 range 0 .. 15; field_2 at 2 range 0 .. 15; end record; for record_type'size use record_byte_length * 8; Then I needed to add a field, which should go before the others: record_byte_length : constant := 6; type Record_Type is record field_0 : Integer_16; field_1 : Integer_16; field_2 : Integer_16; end record; for record_type use record Field_1 at 0 range 0 .. 15; field_2 at 2 range 0 .. 15; end record; for record_type'size use record_byte_length * 8; I forgot to add Field_0 to the rep clause, and the compiler put it at the end (where it didn't belong). Most importantly, the compiler didn't warn me. One solution is to have the compiler write the representation clause for me; in this case, if we make reasonable assumptions about 'record_type', there is only one reasonable rep clause. So I'd like to define: ------------ pragma Deduce_Representation (type_local_name); Specifies that the compiler will assume a record representation clause for 'type_local_name'. Every component of 'type_local_name' shall be of a type that has an explicit size attribute. 'type_local_name' shall have an explicit size attribute, which is equal to the sum of the component sizes. 'type_local_name' shall have an explicit Bit_Order attribute. The representation clause shall layout the components in declaration order, using the sizes specified in the corresponding size attribute. ------------ Most of the record representation clauses I write meet these criteria, and it would prevent maintenance bugs like the above. It would also save time, and avoid other bugs related to writing rep clauses. It would be nice if the assumed rep clause could be endianness-independent, but I suspect that's not possible. It's important that the typical user be able to predict what rep clause the compiler will assume, which is why I've required explicit size attributes on the component types. If we also need to exclude tagged types or disciminated records, that's ok by me. -- -- Stephe