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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d9e66bfe9beb10b9 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 29 Jul 2004 14:58:00 -0500 Date: Thu, 29 Jul 2004 15:58:00 -0400 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: C array to ada record interface References: <0ZudnShYIIM3j5rcRVn-uA@comcast.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.90.114 X-Trace: sv3-lwvINoa2t9wse3cgcx495qPiz9C5yzrYtPMB7TwhIrdgcfTC3nRNEBFsIVB093k4rDmV0u4X4fMBGog!oGQjeDt9BM3iCO1Vrq8J2PlTPgX8j2Z+pAGU3fl3SNERQ6ubgov8BeSfh9jY/w== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.13 Xref: g2news1.google.com comp.lang.ada:2457 Date: 2004-07-29T15:58:00-04:00 List-Id: tmoran@acm.org wrote: > Presumably a 64 bit Ada compiler could be designed to work with a 32 bit > C compiler, with pragma Convention(C, an_access_type) causing > an_access_type to be a 32 bit pointer (with implied additional 32 bits > from a segment or base or just zero, for instance) rather than a 64 bit > pointer. Such a compiler ought to be able to do System.Address <-> access > type conversions for 32 bit, as well as 64 bit, access types, but Ada's > System.Address_To_Access_Conversions could only work for one of those, > right? Perhaps the vendor of such a compiler would offer (non-standard) > package System.Address_To_Access_Conversions.C > for doing the (32 bit or convention C) conversions. Doesn't even have to be a non-standard mode. In theory you could validate a compiler in two modes that support different C compilers or different operating modes. Of course, a compiler that wants to support two different C calling conventions usually has two additional convention names, and probably a compiler switch that tells which one corresponds to convention C. The point I was trying to make was that which C compiler is chosen to bind to, and how it is chosen is outside the scope of the standard. So, in general, the code as written will work. But there is no implementation-independent way to guarantee it. -- Robert I. Eachus "The flames kindled on the Fourth of July, 1776, have spread over too much of the globe to be extinguished by the feeble engines of despotism; on the contrary, they will consume these engines and all who work them." -- Thomas Jefferson, 1821