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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,caabf5265fad78e5 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!d9g2000prh.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Learning Ada (Was: unsigned type) Date: Thu, 9 Jul 2009 08:26:02 -0700 (PDT) Organization: http://groups.google.com Message-ID: <93697a59-b45c-4c50-8265-db9c2b096dc2@d9g2000prh.googlegroups.com> References: <59O1m.404661$4m1.69194@bgtnsc05-news.ops.worldnet.att.net> <62792744-daca-437b-bdee-4b8a21f7ce27@j32g2000yqh.googlegroups.com> <82oq45tj2uu26u6ecsgq70bsjskr9dvghr@4ax.com> <878wj61bpo.fsf_-_@nbi.dk> <4a4f6cce$0$31869$9b4e6d93@newsspool3.arcor-online.net> <4Aa4m.421894$4m1.207252@bgtnsc05-news.ops.worldnet.att.net> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1247153163 25479 127.0.0.1 (9 Jul 2009 15:26:03 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 9 Jul 2009 15:26:03 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: d9g2000prh.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:6922 Date: 2009-07-09T08:26:02-07:00 List-Id: On Jul 8, 5:15=A0pm, "Randy Brukardt" wrote: > "Adam Beneschan" wrote in message > > news:c5a3eb71-0395-4727-b4dd-826b1196d262@m3g2000pri.googlegroups.com... > > >On Jul 6, 4:15 pm, "Randy Brukardt" wrote: > > >> All the standard requires is that Integer is 16-bits > > >You mean "at least 16 bits", right? > > Yes, of course. > > >>, and that Long_Integer > >> (if it exists) is longer than Integer. > > >I think that should be "at least as long"... (3.5.4(25): "the range of > >Integer should be no wider than that of Long_Integer"). =A0Of course, if > >Integer is only 16 bits then Long_Integer must be longer (since > >Long_Integer must be at least 32 bits), but if Integer is 32 bits then > >it appears OK if Long_Integer is the same size as Integer. > > You're correct of course, although I think it is pretty dubious to have a > Long_Integer type with the same range as Integer. Probably it is allowed = to > support another form of compatibility (so that the name exists), but it i= s > always better to not use the type in the first place (unlike Integer, you= 're > never required to use Long_Integer). The reason I thought of for having a compiler vendor define Integer and Long_Integer to be the same size was to assist users who are porting from one target to another, which I think is what you were hinting at. I can imagine a word-addressable target with a 32-bit word size, so that it wouldn't make sense to define Integer as less than 32 bits, but they also might not want to make Long_Integer 64 bits because the operations would involve extra overhead (multiple add- with-carry instructions) that users wouldn't want---and of course they wouldn't want to eliminate Long_Integer entirely. Of course, processors like that may exist only in the textbooks I had to learn from 30 years ago. :) Also, it may be true that users who needed the ability to write portable programs shouldn't have been using the standard types, especially Long_Integer, in the first place. But as compiler vendors, our job is to help our customers accomplish what they need to accomplish, not to sit in judgment of them and say "You're not allowed to use our product" if they're code isn't 100% up to our exacting standards for writing portable code. So instead, we try to write our compilers in the way that will be most helpful. If in some (hypothetical) instances it means making Long_Integer the same size as Integer, then fine. -- Adam