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,4b89102f705d4611 X-Google-Attributes: gid103376,public From: "Marc A. Criley" Subject: Re: The Incredible Shrinking Type Date: 2000/11/07 Message-ID: <3A08092F.E369B323@earthlink.net>#1/1 X-Deja-AN: 690806920 Content-Transfer-Encoding: 7bit References: <3A0703F5.9333AE56@earthlink.net> <8u7gte$7ie$1@nnrp1.deja.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 973608939 158.252.122.238 (Tue, 07 Nov 2000 06:55:39 PST) Organization: Quadrus Corporation MIME-Version: 1.0 NNTP-Posting-Date: Tue, 07 Nov 2000 06:55:39 PST Newsgroups: comp.lang.ada Date: 2000-11-07T00:00:00+00:00 List-Id: Robert Dewar wrote: > > In article <3A0703F5.9333AE56@earthlink.net>, > "Marc A. Criley" wrote: > > > However, when passing an instance of this type as a parameter > to a procedure and > > extracting its 'Size, the result is 64. What happened to the > rest of the bits? > > Granted, they were unused, but still... Where is this > behavior addressed by the > > language (if it is), or is it a freedom granted to compiler > implementor's? > > You are making the common mistake of confusing the size of > a type with the size of objects of the type. Specifying the > size of a type only affects packing and unchecked conversion > in Ada 95 semantics. It does not determine the size of > objects of the type, and there is no requirement that the > size of all objects of the type be the same. Actually I do understand the distinction between the sizes of a type and objects of that type. That's been very well beaten into me over the last couple years. In my case, I guess there's still been a residual reluctance to accept that specifying the size of a type only affects packing and Unchecked_Conversion. Especially since compilers do usually try to utilize that size (in some way, as demonstrated in the example) when allocating objects of that type--implying there is a semantic effect beyond those two areas. However, today, the last of the residual reluctance has finally been cleared away...and I do believe! :-) > > So the real issue here is what you have read in the RM that > implies that the above behavior is expected or not expected. > Actually asking for more than 64 bits for a scalar type is > a bit peculiar anyway (and way out of the portable behavior > required by the RM). > I agree this is a peculiar use. Fortunately I'm not employing that technique, I just want to be able to properly and accurately analyze any such peculiar software that I may come across. Marc A. Criley Senior Staff Engineer Quadrus Corporation