Re: Record representation

[Mark H Johnson <mark_h_johnson@raytheon.com>]

Martin Dowie wrote:

> "Mark H Johnson" <mark_h_johnson@raytheon.com> 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 <stdio.h>

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