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: 103376,5a84d5077c54a29d X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder.news-service.com!newsfeeder.dynfx.net!weretis.net!news.k-dsl.de!aioe.org!not-for-mail From: Keith Thompson Newsgroups: comp.lang.ada Subject: Re: Ada array vs C pointer (call by reference) Date: 27 Jun 2008 15:14:19 -0700 Organization: Aioe.org NNTP Server Message-ID: References: <5df91e99-a972-48f7-b466-3eb05dc0a915@m3g2000hsc.googlegroups.com> <3dcc4a2d-f2f9-4c98-96c8-cd9dd1b090fe@z72g2000hsb.googlegroups.com> NNTP-Posting-Host: udTJGbGWl+bx22XXwco3hA.user.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 Xref: g2news1.google.com comp.lang.ada:925 Date: 2008-06-27T15:14:19-07:00 List-Id: Maciej Sobczak writes: > On 27 Cze, 18:11, Keith Thompson wrote: > > > Ada *cannot* guarantee that Interfaces.C.C_Float is the *right* float, > > > because it does not verify how the C code was compiled and there is a > > > lot of freedom given to C implementers in this area. > > > Same for all other types. > > > > No, Ada can't guarantee it directly. Instead, Ada requires the > > implementation to guarantee it. > > And how the implementation can guarantee it without mandating the > representation on the C compiler? It doesn't *mandate* the representation used by the C compiler; the author of the Interfaces.C implementation has to *know* the representation used by the C compiler. And yes, the fact that different C compilers on the same system might use different representations is an issue. > Consider a C compiler that has a switch that selects the > representation for fundamental types. It is not uncommon. > I can have *the same* program compiled twice by *the same* compiler > and the two versions will differ in representation of their > fundamental types. > > How Ada implementation can guarantee anything in this area? The C compiler invoked with the switch and the same compiler invoked without the switch are logically two different C implementations. The Ada compiler, if it wants to support both of them, might provide two distinct Interfaces.* subpackages, say Interfaces.C_Foo and Interfaces.C_Bar. It's an imperfect solution, but no perfect solution is possible. > > Look at it this way. You have the choice of using > > Interfaces.C.C_Float, which (assuming the Ada implementation gets it > > right), is guaranteed to match C's float > > There is no way to guarantee that. The only way is to name two > compilers and say that *they* are compatible with this and that > switches. But then - there is no added value from Interfaces.C.XXX. I disagree. The developers of the particular implementation of Interfaces.C have done the work of figuring out the characteristics of the particular C implementation, so you don't have to. > > Why would you even > > consider using Float? > > Because the amount of magic and handwaving in interfacing is the same > as with Interfaces.C.C_float, but it is less typing. :-) If you use Interfaces.C.C_float and it doesn't work, you can complain to your Ada compiler vendor, who just might have a solution that's better than anything you or I have thought of. The bottom line is that there's no fundamental reason to assume that Ada's Float and C's float have the same representation, or that an Ada compiler should necessarily follow a C compiler's decisions regarding type representations. Though there's nothing wrong with doing so if it happens to be convenient, as it is in the case of GNAT. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"