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,90f687f65a66617e X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Simple ADA/C Question Date: 1997/03/09 Message-ID: #1/1 X-Deja-AN: 224312027 References: <01bc23b2$ecc64960$64e2b8cd@p5120.bda> <331c6ca7.792732@news.demon.co.uk> <1997Mar6.124303.1@eisner> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-03-09T00:00:00+00:00 List-Id: Larry said <> Well it's always possible, and is equally possible in the case of GNAT. Looking at all current platforms, I don't see any where this possibility is likely to arise (as you know GNAT is on 30-40 platforms now, so we have looked at this issue on a pretty wide range of platforms). We have found one platform, VMS, on which are standard decision to make the Long_Integer type in Ada match long in C, is not appropriate. On VMS type long in C is 32-bits, but we have two conflicting rquirements here, one to be compatible with C in the normal GNAT style, and the other to be compatible with DEC Ada 83. In DEC Ada 83, type Long_Integer is 64-bits, and we decided that this compatibility consideration wins out, so Long_Integer /= long in the VMS version of GNAT. However int is still the same as Integer, and I am still willing to bet that it is very unlikely that any compiler will make any other choice in the forseeable future. Too much user code depends on this identify (and just in case you feel like blaming GNAT, the code I am talking about is millions of lines of legacy Ada 83 code, written long before GNAT existed!)