Can alignment of tagged obj depend on size?

Can alignment of tagged obj depend on size?

[Paul Pukite]

I understand why tagged types have unique properties
with respect to data alignment. But I have trouble 
following why one particular compiler varies the alignment 
based on a component's size.

The following output and code describes the situation.
The composed component is a fixed string of Length = N 
characters. If N < 8 then
  Size of tagged object = 4 + N Bytes
else
  Size of tagged object = 8 + N Bytes
end if

The offset of 4 is consumed by the tag pointer, but for bigger
objects an extra 4 bytes are inserted (as padding?). I can infer
that this might be an optimization for a 64-bit platform
but I compile for a pair of 32-bit machines. I have concerns
but apart from som buggy Ada.Streams code I have no proof
that arbitrary alignment will cause problems in practice. 
From what I understand, only the compiler should care about 
the layout of a tagged type.
Does anyone have a good testing stategy for finding other latent 
bugs that might arise from oddball data representations?

thanks
Paul Pukite

-----------------------
m.wrk> ./tag_rec_size
Len = 0, Size in bytes = 4
Len = 1, Size in bytes = 5
Len = 2, Size in bytes = 6
Len = 3, Size in bytes = 7
Len = 4, Size in bytes = 8
Len = 5, Size in bytes = 9
Len = 6, Size in bytes = 10
Len = 7, Size in bytes = 11
Len = 8, Size in bytes = 16       <---- discontinuity here
Len = 9, Size in bytes = 17
Len = 10, Size in bytes = 18
Len = 11, Size in bytes = 19
Len = 12, Size in bytes = 20
Len = 13, Size in bytes = 21
Len = 14, Size in bytes = 22
Len = 15, Size in bytes = 23
Len = 16, Size in bytes = 24
Len = 17, Size in bytes = 25
Len = 18, Size in bytes = 26
-----------------

package Tag_Rec is
    generic
        N : in Integer;
    package Template is
        type Fixed_String is
            record
                Str : String (1 .. N);
            end record;

        type Root is tagged
            record
                Text : Fixed_String;
            end record;
    end Template;
    -- use generics only to keep from using cut-and-paste
    package Class0 is new Template (0);
    package Class1 is new Template (1);
    package Class2 is new Template (2);
    package Class3 is new Template (3);
    package Class4 is new Template (4);
    package Class5 is new Template (5);
    package Class6 is new Template (6);
    package Class7 is new Template (7);
    package Class8 is new Template (8);
    package Class9 is new Template (9);
    package Class10 is new Template (10);
    package Class11 is new Template (11);
    package Class12 is new Template (12);
    package Class13 is new Template (13);
    package Class14 is new Template (14);
    package Class15 is new Template (15);
    package Class16 is new Template (16);
    package Class17 is new Template (17);
    package Class18 is new Template (18);
end Tag_Rec;

with Text_Io;
with Tag_Rec;
procedure Tag_Rec_Size is
    procedure Report_Size (Chars, Bits : Integer) is
    begin
        Text_Io.Put_Line ("Len =" & Integer'Image (Chars) &
                          ", Size in bytes =" &
                          Integer'Image (Bits / 8));
    end Report_Size;
    Obj0 : Tag_Rec.Class0.Root;
    Obj1 : Tag_Rec.Class1.Root;
    Obj2 : Tag_Rec.Class2.Root;
    Obj3 : Tag_Rec.Class3.Root;
    Obj4 : Tag_Rec.Class4.Root;
    Obj5 : Tag_Rec.Class5.Root;
    Obj6 : Tag_Rec.Class6.Root;
    Obj7 : Tag_Rec.Class7.Root;
    Obj8 : Tag_Rec.Class8.Root;
    Obj9 : Tag_Rec.Class9.Root;
    Obj10 : Tag_Rec.Class10.Root;
    Obj11 : Tag_Rec.Class11.Root;
    Obj12 : Tag_Rec.Class12.Root;
    Obj13 : Tag_Rec.Class13.Root;
    Obj14 : Tag_Rec.Class14.Root;
    Obj15 : Tag_Rec.Class15.Root;
    Obj16 : Tag_Rec.Class16.Root;
    Obj17 : Tag_Rec.Class17.Root;
    Obj18 : Tag_Rec.Class18.Root;
begin
    Report_Size (0, Obj0'Size);
    Report_Size (1, Obj1'Size);
    Report_Size (2, Obj2'Size);
    Report_Size (3, Obj3'Size);
    Report_Size (4, Obj4'Size);
    Report_Size (5, Obj5'Size);
    Report_Size (6, Obj6'Size);
    Report_Size (7, Obj7'Size);
    Report_Size (8, Obj8'Size);
    Report_Size (9, Obj9'Size);
    Report_Size (10, Obj10'Size);
    Report_Size (11, Obj11'Size);
    Report_Size (12, Obj12'Size);
    Report_Size (13, Obj13'Size);
    Report_Size (14, Obj14'Size);
    Report_Size (15, Obj15'Size);
    Report_Size (16, Obj16'Size);
    Report_Size (17, Obj17'Size);
    Report_Size (18, Obj18'Size);
end Tag_Rec_Size;

Re: Can alignment of tagged obj depend on size?

[Ted Dennison]

puk @ umn._edu_ (Paul Pukite) wrote in message news:<3c50db2a.1393453@news.tc.umn.edu>...
> I understand why tagged types have unique properties
> with respect to data alignment. But I have trouble 
> following why one particular compiler varies the alignment 
> based on a component's size.

One might take a further step and ask why you care. In Ada, if you
care about such things, you use representation clauses to force the
issue. Otherwise, you are telling the compiler to store it any way it
wants. If you don't give any rep clauses and the compiler chooses some
bizzare (to you) alginment and ordering, that's its business.