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.7 required=5.0 tests=BAYES_00,MSGID_RANDY 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 X-Google-ArrivalTime: 2000-11-08 21:50:16 PST Path: supernews.google.com!sn-xit-02!supernews.com!isdnet!newsfeeds.belnet.be!news.belnet.be!news.tele.dk!128.230.129.106!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: Robert Dewar Newsgroups: comp.lang.ada Subject: Re: The Incredible Shrinking Type Date: Thu, 09 Nov 2000 05:41:31 GMT Organization: Deja.com - Before you buy. Message-ID: <8uddeb$2e6$1@nnrp1.deja.com> References: <3A0703F5.9333AE56@earthlink.net> <8u7gte$7ie$1@nnrp1.deja.com> <3A0816D4.E980EAFB@cadwin.com> <8ua2vm$b8l$1@nnrp1.deja.com> <3A091116.75D56C2A@cadwin.com> NNTP-Posting-Host: 205.232.38.240 X-Article-Creation-Date: Thu Nov 09 05:41:31 2000 GMT X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) X-Http-Proxy: 1.0 x68.deja.com:80 (Squid/1.1.22) for client 205.232.38.240 X-MyDeja-Info: XMYDJUIDrobert_dewar Xref: supernews.google.com comp.lang.ada:1934 Date: 2000-11-09T05:41:31+00:00 List-Id: In article <3A091116.75D56C2A@cadwin.com>, Nicolas Brunot wrote: > > > to avoid making the assumptions).> > > Nobody said that, except you justifying type shrinking by RM requiring > portability ... > > > > > Odd is not the right word, unexpected, unsafe or illogical > would be more appropriate Unexpected -- you have no basis for expecting anything Unsafe -- If your code depends on your unwarranted expectations, then it is your code that is unsafe! Illogical -- Well I can't be responsible for people's logic. As I explained in a previous note, our convention for parameter'Size, based on what we see most Ada 83 compilers doing, is to have this query return the actual size used by the value, rather than the allocated size of the object. Consider why we do this. Suppose you have the following: x : integer; for x'size use 32; y : integer; for y'size use 64; procedure p (m : in integer) is begin Put (m'size); end; ... p(x); p(y); DO you really expect (accordingly to your logic) to see 32 and 64 here? If you do, you are asking for an amazing overhead to be added to all procedure calls, namely an extra hidden parameter for every parameter giving the allocated length of the calling object. Surely you don't expect this ... > Right, the "normal" behavior (without shrinking) would just be > suggested by common sense Common sense has no place in this discussion if it is not backed up by the RM. The RM is the *only* thing you can rely on here. I cannot tell you how many portability problems are caused by programmers who rely on their common sense rather than an exact knowledge of what is and is not guaranteed by the definition of the language. > and also ... by gnat documentation itself ... Not sure what you are referring. Please provide quote here. Note that in all this discussion, this is a VERY strange type to define in the first place, which is why it generates a warning that there are unused bits. The whole purpose of this warning is to warn that there are bits in the allocated object that do not participate in any way in what is going on! The rules about parameters in GNAT are really intended for the variant record case, where there really is an issue, and as I mentioned before, the RM leaves open whether 'Size on a variant record parameter returns the allocated size or the actual size. We chose the latter because Ada 83 compilers seem to have made that choice (there is a section in the GNAT RM that specifically discusses this). Sent via Deja.com http://www.deja.com/ Before you buy.