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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ad4aec717fd8556e X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: 'size attribute inheritance Date: 1997/08/10 Message-ID: #1/1 X-Deja-AN: 263374123 References: <33ECF679.4B5D@lmco.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-08-10T00:00:00+00:00 List-Id: In article <33ECF679.4B5D@lmco.com>, Carlos Palenzuela wrote: > type Integer_16 is range -(2**15) .. (2**15)-1; > for Integer_16'size use 16; This is the Size that should be chosen by default, anyway, because of RM-13.3(55). But the sizes of the various subtypes in this example seem completely irrelevant, since what you care about is the size of the components Year and Month, and you've set those to 16 using a record rep clause. So even if you set Integer_16'Size to 999 (and can get the compiler to listen), the size of both components will still be 16. The ARG has had endless arguments about the exact meaning of 'Size. See AI95-109, if you're interested. > subtype Natural_16 is Integer_16 range 0 .. Integer_16'last; > > subtype Month_Type is Natural_16 range 0..11; > > type Date_Type is > record > Year : Natural_16; > Month : Month_Type; > end record; > > for Date_Type use > record > Year at 0 range 0 .. 15; > Month at 0 range 16 .. 31; > end record; > ... > When running this code, we get a bus alignment error. We tracked >it > down to the fact that the compiler does NOT really allocate 16 bits > for Month with subtype Month_Type. We assumed that since >Integer_16 > had been set up with 'size attribute of 16, subtype Natural_16 >would > inherit that and so Month_Type would also inherit it. I might >expect > based on 13.3 (55) that Month_Type'size = 4 and then on 13.3 (43) >that > Month'size >= 4. That would be true if there were no record rep clause, but there is, so Month'Size = 16. See also AARM-13.5.2(4.b). >...Perhaps the confusion is that only the attribute > itself and not its specific value is what is inherited; I don't see > anything in the ARM which says one way or the other. > > Putting a 'size attribute on the subtype resulted in a syntax error > [assumedly based on 13.3 (48)]. Correct. >...It's not necessarily so bad that > Month_type'size and Month'size are different from Integer_16'size, >but > I would at least expect the values of Month to be right-justified >in > the record-component field if Month'size < Integer_16'size (as >here), > but instead it is left-justified! Is there a justification in the >ARM > for this or is this a compiler issue? The RM says how many bits there are (in this case anyway), but it doesn't say anything about how the compiler uses those bits. I guess the presumption is that the compiler will use a reasonable representation. >...We worked around this >problem > by setting up Month_Type as a type, rather than a subtype, and > assigning it a 'size of 16, but the issue still has me perplexed. Strange. I suspect a compiler bug, but I'm not exactly sure what you meant by "right justified" above -- is that an endian-independent term? By the way, if you're using this record to interface to the rest of the world (input from outside Ada, such as hardware or C code), then I suggest you don't use ranges like 0..11. I think it's generally safer (less likely to cause erroneous execution) if you make sure all the record fields have ranges that *exactly* fit within the number of bits allotted. Once the data is inside the Ada world, you can then range check it, and put it into a more reasonable data structure, if desired. - Bob