Ada : Variant size in record type

Question

I having some trouble with the type Record with Ada. I'm using Sequential_IO to read a binary file. To do that I have to use a type where the size is a multiple of the file's size. In my case I need a structure of 50 bytes so I created a type like this ("Vecteur" is an array of 3 Float) :

type Double_Byte is mod 2 ** 16; for Double_Byte'Size use 16;

type Triangle is
    record
        Normal : Vecteur(1..3);
        P1 : Vecteur(1..3);
        P2 : Vecteur(1..3);
        P3 : Vecteur(1..3);
        Byte_count1 : Double_Byte;
    end record;

When I use the type triangle the size is 52 bytes, but when I take the size of each one separetely within it I find 50 bytes. Because 52 is not a multiple of my file's size I have execution errors. But I don't know how to fix this size, I ran some test and I think it come from Double_Byte, because when I removed it from the record I found a size of 48 bytes and when I put it back it's 52 bytes again.

Thanks you for your help.

Answer 1

The compiler is in no way obligated to use a specific size for Triangle unless you specify it. As you don't, it chooses whatever size it sees fit for fast access to the data. Even if you specify representation details for every component type of the record, the compiler might still choose to use more space for the record itself than necessary.

Considering the sizes you give, it seems obvious that one component of Vecteur has 4 bytes, which gives a total payload of 50 bytes for Triangle. The compiler now chooses to add 2 bytes padding, so that the record size is a multiple of the size of a 4-byte word. You can override this behavior with:

for Triangle'Size use 50 * 8;

This will force the compiler to use only 50 bytes for the record. As this is a tight fit, there is only one way to represent the record, and no further specification is necessary. If you do need to specify how exactly the record is represented, you can use a record representation clause.

Edit:

The representation clause specifies the size for the type. However, each object of this type may still take up more space unless you additionally specify

pragma Pack (Triangle);

Edit 2:

After Simon's comment, I had a closer look at this and realized that there is a far better and cleaner solution. Instead of setting the 'Size and using pragma Pack, do this:

for Triangle use record at mod 2;
   Normal      at 0  range 0 .. 95; 
   P1          at 12 range 0 .. 95;
   P2          at 24 range 0 .. 95;
   P3          at 36 range 0 .. 95;
   Byte_count1 at 48 range 0 .. 15;
end record;

The initial mod 2 defines that the record is to be aligned at a multiple of 2 bytes. This eliminates the padding at the end without the need of pragma Pack (which is not guaranteed to work the same way on every compiler).

Answer 2

Given Simon's latest comment, it may be impossible to do this portably using Sequential_IO; namely, reading the file on some machines (which don't support unaligned accesses) may leave half its contents unaligned and therefore liable to fail when you access them.

I can't help feeling that a better solution is to divorce the file format (which is fixed by compatibility with other systems) from the machine format (which is not). And therefore moving to Stream_IO and writing your own Read and Write primitives where necessary (e.g. to pack the odd sized Double_Byte component into 2 bytes, whatever its representation in memory) would be a more robust solution.

Then you can guarantee a file format compatible with other systems, and an internal memory format guaranteed to work.