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.3 required=5.0 tests=BAYES_00,FROM_ADDR_WS,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,bfda446dad8e3c75,start
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-01-24 22:09:15 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.uchicago.edu!vixen.cso.uiuc.edu!hardy.tc.umn.edu!laurel.tc.umn.edu!not-for-mail
From: puk @ umn._edu_ (Paul Pukite)
Newsgroups: comp.lang.ada
Subject: Can alignment of tagged obj depend on size?
Date: Fri, 25 Jan 2002 06:11:49 GMT
Organization: University of Minnesota (umn . edu)
Message-ID: <3c50db2a.1393453@news.tc.umn.edu>
Reply-To: pukite@mr.net
X-Trace: laurel.tc.umn.edu 1011938953 12535 128.101.250.81 (25 Jan 2002
 06:09:13 GMT)
X-Complaints-To: usenet@laurel.tc.umn.edu
X-Newsreader: Forte Free Agent 1.11/32.235
Xref: archiver1.google.com comp.lang.ada:19298
Date: 2002-01-25T06:11:49+00:00
List-Id: <comp.lang.ada>

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;