Pro*Ada and Gnat

Pro*Ada and Gnat

[J-P. Rosen]

We have been unable to use Pro*Ada (Oracle) with Gnat. Apparently,
Pro*Ada uses heavily unchecked_conversions between pointers and
adresses, and other doubtful features; has anyone succeded to use
Pro*Ada with Gnat ?

(Side note: in the meantime, we use Pro*C to write an adaptator ring
that interfaces nicely with Ada, thanks to the new interfacing
features).
+------------------------------------o-------------------------------------+
|   J-P. Rosen                       |    Rosen.Adalog@wanadoo.fr          |
|   ADALOG - 27 avenue de Verdun     |    Tel: +33 1 46 45 51 12           |
|   92170 Vanves - FRANCE            |    Fax: +33 1 46 45 52 49           |
+------------------------------------o-------------------------------------+

Re: Pro*Ada and Gnat

[Brad Balfour]

In article <5f9hlt$7j9@hetre.wanadoo.fr>, Rosen.Adalog@wanadoo.fr wrote:

>We have been unable to use Pro*Ada (Oracle) with Gnat. Apparently,
>Pro*Ada uses heavily unchecked_conversions between pointers and
>adresses, and other doubtful features; has anyone succeded to use
>Pro*Ada with Gnat ?

In 1995 and early 1996, the Airfields project (one of the AJPO sponsored
Ada 95 Transition Partnership Projects) ran up against this same barrier.
The project's conclusion was that the Pro*Ada bindings and tools are
compiler specific -- they only work with the Ada 83 VADS compiler and no
other. The project attempted to make use of the suggestions from ACT
regarding fat vs. thin pointers. However, this was not enough to overcome
the compiler specific choices made in the Pro*Ada bindings. In many
places, the binding does not hard code rep spec values, but rather depends
on the memory size allocations that VADS chooses for Ada objects to match
the C code. GNAT's choices did not match. Since the C headers are *not*
provided with Pro*Ada, and the Ada code does not have rep specs, the
project was unable to match GNAT to the Pro*Ada bindings.

Instead, this project made use of the Ada SQL Connect product from OIS
<http://www.ois.com>. The software enabled the use of Oracle from Ada
95/GNAT via ODBC. It worked very well.

Brad

--
Brad Balfour
AJPO Ada 95 Transition Support          SIGAda WWW Server
CACI, Inc.                                http://www.acm.org/sigada/
(703) 277-6767                          and also try:
bbalfour@std.caci.com                     http://www.adahome.com/
3930 Pender Drive       Fairfax, VA 22030
   "...they even have rules for exceptions" -- Dewar and Schonberg

Re: Pro*Ada and Gnat

[Laurent Guerby]

Rosen.Adalog@wanadoo.fr (J-P. Rosen) writes:
> We have been unable to use Pro*Ada (Oracle) with Gnat. Apparently,
> Pro*Ada uses heavily unchecked_conversions between pointers and
> adresses, and other doubtful features; has anyone succeded to use
> Pro*Ada with Gnat ?

   Two GNAT features are of a great help in this kind of situation:

- Compile time warnings about Unchecked_Conversion between types with
  different sizes,

- Size representation clause on access types.

   Example:

   type P is access String; -- by default fat (double) pointer with GNAT
   for P'Size use Integer'Size; -- force thin pointer

   function F is new Unchecked_Conversion (P, Integer);
   -- no more warnings ;-)

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Pro*Ada and Gnat

[Robert Dewar]

Laurent Guerby said

<<   for P'Size use Integer'Size; -- force thin pointer>>

This is bad advice, it will not work on a 64-bit implementation of GNAT
such as you will find on the Alpha, where pointer size and integer size
are different, instead use the form I gave in my previous message:

     for P'Size use Address'Size;

Re: Pro*Ada and Gnat

[Robert Dewar]

J-P Rosen asks

<<We have been unable to use Pro*Ada (Oracle) with Gnat. Apparently,
Pro*Ada uses heavily unchecked_conversions between pointers and
adresses, and other doubtful features; has anyone succeded to use
Pro*Ada with Gnat ?>>

Note that if you have pointers to unconstrained arrays, which are normally
represented as double ("fat") pointers in GNAT, you can force an alternative
single ("thin") pointer representation with a size clause:

   for x'size use address'size;

and this may make your code more ready to do battle with doubtful features :-)

Re: Pro*Ada and Gnat

[J-P. Rosen]

Thanks to all those who responded, it seems we got the simplest
approach (use Pro*C).

And I think my client will write a note to Oracle corp. to tell them
what he thinks about their product...
+------------------------------------o-------------------------------------+
|   J-P. Rosen                       |    Rosen.Adalog@wanadoo.fr          |
|   ADALOG - 27 avenue de Verdun     |    Tel: +33 1 46 45 51 12           |
|   92170 Vanves - FRANCE            |    Fax: +33 1 46 45 52 49           |
+------------------------------------o-------------------------------------+

Re: Pro*Ada and Gnat

[Ed Bruce]

J-P. Rosen wrote:
> 
> Thanks to all those who responded, it seems we got the simplest
> approach (use Pro*C).
> 
> And I think my client will write a note to Oracle corp. to tell them
> what he thinks about their product...

I can tell you right now that Oracle doesn't care. They have already
announced that they will no longer support their Pro*Ada product past
it's 1.8 release. They are moving all support into their Ada Module
product. This product is currently worse then Pro*Ada as it doesn't
support aggregate data types.

-- 

Ed Bruce
<Bruce@ha.hac.com>
<ebruce@iquest.com>