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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c70bb16b3813e0fd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-11-20 03:38:03 PST Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!panix!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody From: dewar@cs.nyu.edu (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Ada Portability... NOT! Date: 19 Nov 1994 11:55:18 -0500 Organization: Courant Institute of Mathematical Sciences Message-ID: <3alalm$9di@gnat.cs.nyu.edu> References: <199411182104.PAA04854@mail.cs.utexas.edu> NNTP-Posting-Host: gnat.cs.nyu.edu Date: 1994-11-19T11:55:18-05:00 List-Id: It is probably a reasonable implementation choice to restrict reals to be on a properly aligned boundary, since it is an annoying amount of fiddling to deal with unaligned floating-point stuff, and yes, of course most processors *do* require floating-point values to be aligned. When you use rep clauses you are definitely wandering into the area of implementation dependent non-portable constructs (most appropriately, since one of the functions of rep clauses is to deal with special target dependent requirements). There is certainly no *requirement* that an implementation reject these declarations on a RISC machine, the code generator could generate the code to fiddle around and copy the value. Is it a good idea to do this behind the scenes? Not clear. Suppose a user just casually wrote rep clauses to pack the data in a way that worked fine on one machine but generated long inefficient sequences of code on another, do you want to be allowed or stopped? Either answer is possible. I certainly would never have written the original code, and I certainly would never have written it expecting it to be portable. Writing portable code in Ada does not come for free, it requires some consideration of what is and what is not implementation dependent, and this is especially true of writing portable code containing rep clauses. A more portable approach in your particular case is to read the data into a byte stream (in Ada 9X, use a Storage_Array), and then use unchecked conversion to convert the data to usable floating-point form. Isn't that interesting? The above advice says that you can make the code *more* portable by using unchecked_conversion. Often people have a knee-jerk reaction to avoid UC in portable code, but that's quite misinformed. Just as a careful C programmer will use (carefully chosen) cross-type casts to achieve portability, a careful Ada programmer can use (carefully chosen) unchecked conversions. Actually in Ada 9X, this sort of problem is much better handled using streams in any case.