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,cef1e23795181e0c X-Google-Attributes: gid103376,public From: tmoran@bix.com (Tom Moran) Subject: Re: Alternate to Unchecked_Conversion - Portable? Date: 1999/02/22 Message-ID: <36d09fd9.15766741@news.pacbell.net>#1/1 X-Deja-AN: 446887037 References: <36d05e39.0@news.pacifier.com> X-Complaints-To: abuse@pacbell.net X-Trace: typhoon-sf.pbi.net 919644000 206.170.2.248 (Sun, 21 Feb 1999 16:40:00 PDT) Organization: SBC Internet Services NNTP-Posting-Date: Sun, 21 Feb 1999 16:40:00 PDT Newsgroups: comp.lang.ada Date: 1999-02-22T00:00:00+00:00 List-Id: >a similar function to >Unchecked_Conversion. Locating two data structures at the same address by >defining the first normally and then using an address clause to locate the >second at the same address as the first >... >My question is: is this portable? You have similar record layout worries with address overlay and Unchecked_Conversion. If you use a representation clause to control all the parts of the layout, then the two layouts should be the same - if you don't, then two compilers would be free to make them different. It seems unlikely two compilers would choose different endian-ness for multi-byte entities on the same machine, but clearly they might on different machines, so IO is a worry. If you're careful and thorough, you should be able to make something portable, but you ought to check the compilers you're using (and again when you get a newer version of either compiler).. With Unchecked_Conversion, at least the compiler can warn you if the two things aren't the same size, which of course it can't if they merely have the same address. If some later change modifies the layout or adds to the size of one of the two things, the compiler can't give you any warnings. With Unchecked_Conversion, the only time you transform one object into another is when you call the instantiated Unchecked_Conversion function. With the address overlay, you've got aliasing and possibly multitasking to worry about - any change to either object is instantly reflected in the other, and any change to a temporary compiler generated copy (in registers, say) of one object fails to be reflected in the other. With Unchecked_Conversion, it's easy to use your editor to find any occurrences, and then occurrences of the instantiated conversion. With address overlay, you can find the rep clauses, and then the objects, but following them through their aliases (as one is passed to a procedure either by reference or by copy in/out, say) will get real tedious and error prone. With Unchecked_Conversion, you have a function able to transform *any* object of the one type to the other. With address overlay, you have a single specific object transformed implicitly to another single specific object. That said, yes there do exist times when address overlay is the best, or only, thing to do.