Re: Simple ADA/C Question

[kst@sd.aonix.com (Keith Thompson)]

In <dewar.857350486@merv> 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 <http://www.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