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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,48bbfdbc3683ed X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: Tagged Rep Spec Date: 1999/06/28 Message-ID: <37778A4E.2C060F@pwfl.com>#1/1 X-Deja-AN: 494785819 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <7k5mop$n0i$1@nnrp1.deja.com> <7l04v5$61p$1@nnrp1.deja.com> Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada Date: 1999-06-28T00:00:00+00:00 List-Id: Robert Dewar wrote: > > These are not reasons for not specifying a rep clause, they > are just reminders that the rep clause will likely be > impl dependent, but then MANY rep clauses are impl dependent. > That's fair enough. If I can always count on the compiler I have (and its future versions!) putting a 32 bit tag at the front of the record, I can build useful stuff from there. But it would still be nice if there were attributes to determine the tag placement (or even if there is a tag - one might imagine an implementation where there is no tag - or maybe like arrays, it is "invisible" WRT representation clauses.) > In the case of tagged types, the tag in GNAT is a single pointer > sized object at offset 0 in the record. Rep clauses can be > freely used to position the specified fields of the type, > providing that the space for the tag is not stomped on. > Yes, but there is a problem with child types. I don't so much mind if there is a tag in front of the record if it is consistently applied, because I can consistently remove it when necessary. However, when child records are created, they are forced onto longword alignments which can't seem to be overriden with a rep clause. So if I want to capture all of my "real" data and bypass "spare" fields allocated by the compiler, I have no reliable way of doing it. With just the tag, I might be able to compute ((X'Size / System.Storage_Unit) - 4) the proper number of raw bytes to move, but without good control of the placement of all subsequent fields, the rep clause quickly becomes useless. Unless there is some trick that I'm missing? MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/