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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,54a7591bed8148f2 X-Google-Attributes: gid103376,public Path: g2news1.google.com!news2.google.com!news.maxwell.syr.edu!border1.nntp.dca.giganews.com!border2.nntp.sjc.giganews.com!nntp.giganews.com!cyclone-sf.pbi.net!151.164.30.34!cyclone.swbell.net!bos-service1.raytheon.com!dfw-service2.ext.ray.com.POSTED!53ab2750!not-for-mail From: Mark H Johnson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Record representation References: <40c6d3d1$1_1@baen1673807.greenlnk.net> <40c7407c$1_1@baen1673807.greenlnk.net> In-Reply-To: <40c7407c$1_1@baen1673807.greenlnk.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <27Kxc.5$oX2.2@dfw-service2.ext.ray.com> Date: Wed, 09 Jun 2004 15:08:18 -0500 NNTP-Posting-Host: 192.27.48.39 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.ray.com 1086811710 192.27.48.39 (Wed, 09 Jun 2004 15:08:30 CDT) NNTP-Posting-Date: Wed, 09 Jun 2004 15:08:30 CDT Organization: Raytheon Company Xref: g2news1.google.com comp.lang.ada:1329 Date: 2004-06-09T15:08:18-05:00 List-Id: Martin Dowie wrote: > "Mark H Johnson" wrote in message > news:c2Gxc.1$oX2.0@dfw-service2.ext.ray.com... > >>Let's generalize the situation slightly. What do you suggest be done if >>you change the data type from an Integer to a Natural? Using GNAT on >>x86's, Natural'Size is 31 (not 32) so that would imply setting AA'Size >>to 310 (and not 320) w/ a real pain in the *ss due to packing / >>unpacking of the data. > > > Could use a new attribute 'Object_Size (which would be 32). > Yes - but its not part of Ada 95. The alternative of course is to create a dummy object and then take 'Size of the object instead. We have some code that uses that approach - one example follows: type Msg_Rec is record Blah1 : Set.Integer_32; Blah2 : Set.Real_15; end record; type Msg_Rec_Ptr is access Msg_Rec; Dummy_Msg_Rec : constant Msg_Rec := (Blah1 => 0, Blah2 => 0.0); Msg_Rec_Size : constant Natural := Dummy_Msg_Rec'Size; The last line being the size to be passed to our messaging system. It must be the size of an object, not the size of the type. This type of construct (using something like Msg_Rec_Size as a constant) may also help in specifying the values you need in your example. > > >>I remember a private email exchange with Robert Dewar about something >>similar to this a few years ago. Let me see if I can dig up the >>suggestions he had to improve the portability of your code. > > > That would be very interesting - TIA > Let's see what I have... A series of messages related to alignment - not quite sure this is exactly the kind of problem you are looking at but I'll post this for reference in case it helps. We have a data type that has 'Size of 400. Note that 400 is not divisible by 32. Two years ago, ACT changed the default alignment for some data types to 4 (was 1) and broke our code. An example recoded in C was [the original Ada has a bazillion comments]... #include struct taxi_select_criteria { short c_word; char apply_to; char starting_at; short mask_value; char apply_mask; char spare; } A; struct select_request { struct taxi_select_criteria select_with[6]; char apply_selection; char spare; } B; struct select_request C[10]; int main() { printf("Ada size of taxi_select_criteria is %d\n", sizeof(A)*8); printf("Ada size of select_request is %d\n", sizeof(B)*8); printf("Ada size of save_taxi_packets is %d\n", sizeof(C)*8); return 0; } which should print out the values of 64, 400, and 4000. None of the data items are 4 bytes long and I argued (unsuccessfully I may point out) that I should not have to specify 'Alignment of taxi_select_criteria nor select_request to get the array of select_request fully packed. Let me briefly quote part of my argument at the time: >[1] Let me look a little bit into the future when "word size" changes >from 4 to 8. If I follow what is stated to its logical conclusion, the >64 bit compiler can reject packed arrays that the 32 bit compiler >accepts. Gnat is not so restrictive - if I add alignment clauses. But >even for gnat - to be portable, I must add those alignment clauses to >every structure that currently fits on a four byte word size and will >not fit on an eight byte word size IF it is [or might be] put into a >packed array. Yet another migration nightmare ahead of many of us. However, I did get a message about a year ago indicating that the alignment rules were relaxed somewhat so the original code might be OK now. --Mark