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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f84a857bba053719,start X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-96" Subject: Re: System.Address_to_Access_Conversions Date: 1998/07/15 Message-ID: <98071509523514@psavax.pwfl.com>#1/1 X-Deja-AN: 371708569 Sender: Ada programming language Comments: To: nabbasi@earthlink.net X-VMS-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" Newsgroups: comp.lang.ada X-VMS-Cc: SMTP%"nabbasi@EARTHLINK.NET",CONDIC Date: 1998-07-15T00:00:00+00:00 List-Id: nabbasi@EARTHLINK.NET writes: >In article <6ofqvs$alm@hacgate2.hac.com>, "David says... > >> Typically you will want to use a record representation clause to >>make the memory layout correspond to the harware requirements. Using a >>tagged type in such a sitiuation is not a good idea, because the tag is a >>"hidden" data field within the record which certainly will have no >>correspondence with the hardware-required memory layout. >> > >I read somewhere that the tag position within a record is always defined, >it is the first element always, right? not sure what's its size, I assume >it is an address to someother tag related information somewhere else, so its >size is also known, right? > I went around the block on this one a while back. So far as I could determine, the Ada95 RM defines nothing about where the tag resides - or for that matter that it has to be kept with the record at all, etc. I think they wanted to say "The most obvious way to implement it is with a tag field that is hidden within the record - but if you think of a more clever way of doing it, the standard won't get in your way." The bad news is that not only does the standard not specify how big or where the tag field lies, but it also gives you no control over where to put it. You can't use representation clauses to control the positioning of the tag or its size and you can't control its content. This made tagged records a major nuisance to me when trying to utilize them in a communications situation where I wanted to beam the bits down a wire. There is a way to use streams to get rid of the tag information if you need to do it, but if you are in some way interested in utilizing tagged records to overlay physical hardware, etc., you will find there are no good answers. At best, you can determine how the tag is handled by the specific version of the specific compiler you are using & build your representation around that information. You may fight loosing battles with the compiler over word alignment and memory allocation because apparently compilers won't trust you when you say "No, I really mean it: put this field here." In the end you will have a non-portable solution that is volatile and subject to change without notice by your compiler vendor. If you come across information that suggests a solution to controlling representation of tagged record types that sounds standard and portable, I'd be interested in hearing about it. MDC Marin David Condic, Senior Computer Engineer Voice: 561.796.8997 Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600 Fax: 561.796.4669 West Palm Beach, FL, 33410-9600 Internet: CONDICMA@PWFL.COM ============================================================================= "The race is not always to the swift, nor the battle to the strong - but that's the way to bet." -- Damon Runyon =============================================================================