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: kst@sd.aonix.com (Keith Thompson) Subject: Re: Simple ADA/C Question Date: 1997/03/04 Message-ID: #1/1 X-Deja-AN: 222936395 Sender: news@thomsoft.com (USENET News Admin @flash) X-Nntp-Posting-Host: pulsar References: <01bc23b2$ecc64960$64e2b8cd@p5120.bda> Organization: Aonix, San Diego, CA, USA Newsgroups: comp.lang.ada Originator: kst@pulsar Date: 1997-03-04T00:00:00+00:00 List-Id: In dewar@merv.cs.nyu.edu (Robert Dewar) writes: [...] > I understand that position, but the trade off is between piles of annoying > conversions and much more straightforward code in some instances. Then define an imported function that returns Interfaces.C.int, and a wrapper function that converts the result to Integer. If you inline the wrapper, there should be no runtime overhead as long as int and Integer have the same representation. Or overload unary "+" as a conversion operator (yes, that convention is a bit controversial). > However, this was not the issue, Bob said that using int on the C side > and Integer on the Ada side definitely *will* cause problems, and this > is plain wrong! That's true. I'd almost be happier if it were guaranteed to cause problems. The worst kind of bug is the one that doesn't show up until years later. > Are there any compilers incidentally where int in C is not the same > as Integer in Ada? Certainly int = Integer on all GNAT compilers. > Hard to believe that anyone would deviate from this equivalence. Given > that the choice of what Integer means in Ada is definitely implementation > dependent, it seems foolish to make any other choice. I don't know, but with all the new 64-bit processors showing up, presumably the C compiler implementers are facing a tradeoff between backwards compatibility (32-bit int) and using the representation that makes the most sense for the target machine (64-bit int). I can easily imagine two different C compilers (or even two different modes of the same compiler) making the choice differently on the same system. Has this actually happened? I don't know. Even if this isn't a problem for 64-bit processors, who knows what will happen with the next generation after that? Whenever possible, I like to program in a way that won't cause future maintenance programmers to curse my name. 8-)} If you feel you must write code that assumes the same representation for int and Integer, consider adding something like this: subtype Assertion is Boolean range True .. True; Integer_Same_Size : constant Assertion := Interfaces.C.int'Size = Standard.Integer'Size; Then you'll at least get a warning if you try to port your software to a system on which the assertion fails. (I don't think the language requires a warning, but I think all existing compilers will issue one.) Or, if you want to get really fancy and guarantee catching it at compile time, try this: Integer_Same_Size : constant Boolean := Interfaces.C.int'Size = Standard.Integer'Size; type Dummy(Discr: Boolean) is record case Discr is when False => null; when Integer_Same_Size => null; -- must be True end case; end record; If the condition (which must be static) is false, the choices will overlap, which is illegal. Again, this shouldn't have any run-time overhead. -- Keith Thompson (The_Other_Keith) kst@sd.aonix.com <*> TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706 "Humor is such a subjective thing." -- Cartagia