c2ada bug report filed

c2ada bug report filed

[Jerry]

I made a bug report for c2ada at
http://sourceforge.net/tracker/?func=detail&aid=3259603&group_id=203517&atid=985906

This isn't  super important but I was going to try to use it to
convert a 900-line C example file for the PLplot project.

I was trying to build on OS X 10.6.6 and ran into C errors relating to
undeclared variables.

Jerry

Re: c2ada bug report filed

[Simon Wright]

Jerry <lanceboyle@qwest.net> writes:

> I made a bug report for c2ada at
> http://sourceforge.net/tracker/?func=detail&aid=3259603&group_id=203517&atid=985906
>
> This isn't  super important but I was going to try to use it to
> convert a 900-line C example file for the PLplot project.
>
> I was trying to build on OS X 10.6.6 and ran into C errors relating to
> undeclared variables.

SF changed its wiki software a while back, with the result that the
c2ada web site is now very uninformative.

You should be using the 'portability' branch:

* go to branches/portability in your checkout
* edit setup (you'll need to change the Python version, at least)
* ./setup
* make

Bets of luck!

Re: c2ada bug report filed

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Jerry <lanceboyle@qwest.net> writes:
>
>> I made a bug report for c2ada at
>> http://sourceforge.net/tracker/?func=detail&aid=3259603&group_id=203517&atid=985906
>>
>> This isn't  super important but I was going to try to use it to
>> convert a 900-line C example file for the PLplot project.
>>
>> I was trying to build on OS X 10.6.6 and ran into C errors relating to
>> undeclared variables.
>
> SF changed its wiki software a while back, with the result that the
> c2ada web site is now very uninformative.
>
> You should be using the 'portability' branch:
>
> * go to branches/portability in your checkout
> * edit setup (you'll need to change the Python version, at least)
> * ./setup
> * make
>
> Bets of luck!
  ^^^^
  Best (of course).

I've now merged the portability branch back into trunk, and updated
setup so it chooses Python 2.6. Builds OK here (10.6.7, XCode 3.2.6).

I've restored the wiki content, but have yet to make it the standard
home page (and there are still bits of it I don't understand; it got
majorly mangled somewhere along the line before I got hold of it).

Re: c2ada bug report filed

[Jerry]

On Mar 30, 1:03 pm, Simon Wright <si...@pushface.org> wrote:
> Simon Wright <si...@pushface.org> writes:
> > Jerry <lancebo...@qwest.net> writes:
>
> >> I made a bug report for c2ada at
> >>http://sourceforge.net/tracker/?func=detail&aid=3259603&group_id=2035...
>
> >> This isn't  super important but I was going to try to use it to
> >> convert a 900-line C example file for the PLplot project.
>
> >> I was trying to build on OS X 10.6.6 and ran into C errors relating to
> >> undeclared variables.
>
> > SF changed its wiki software a while back, with the result that the
> > c2ada web site is now very uninformative.
>
> > You should be using the 'portability' branch:
>
> > * go to branches/portability in your checkout
> > * edit setup (you'll need to change the Python version, at least)
> > * ./setup
> > * make
>
> > Bets of luck!
>
>   ^^^^
>   Best (of course).
>
> I've now merged the portability branch back into trunk, and updated
> setup so it chooses Python 2.6. Builds OK here (10.6.7, XCode 3.2.6).
>
> I've restored the wiki content, but have yet to make it the standard
> home page (and there are still bits of it I don't understand; it got
> majorly mangled somewhere along the line before I got hold of it).

Thanks for the updates, Simon.

I don't expect much handholding here but I thought that I should at
least report my results.

I updated my system to OS X 10.6.7 and Xcode to 3.2.6.

After downloading c2ada from SVN, rev 23, I cd-ed to the distribution
directory and built by ./setup and make which created c2ada. I then
ran c2ada (still cd-ed to the distribution dir) on two very small C
programs in another directory. The first one

int main(void)
{
    int a;
    a = 1;
    return 0;
}

resulted in a useful Ada package. However, the second one

#include <stdio.h>
int main(void)
{
    printf("Hello World\n");
    return 0;
}

resulted in just a skeleton Ada package with no useful lines. (Other
files were also created.) The terminal output had a few lines that
looked troublesome. I tried with -I/usr/include which is where stdio.h
is stored but it made no difference in the output, at least with
respect to the corresponding Ada package.

Jerry

Re: c2ada bug report filed

[Simon Wright]

Jerry <lanceboyle@qwest.net> writes:

> I don't expect much handholding here but I thought that I should at
> least report my results.

Thanks. I have to admit I joined the C2Ada project because it seemed it
might come in handy, and I really like things to be done portably if at
all possible. I'm far from an expert in the package. I suspect you'd
need to add some project-specific tweaks for a particular
project. Certainly "c2ada /usr/include/tcl.h" on its own doesn't produce
anything remotely useful; I'm not sure what Terry Westley did to get it
to provide the initial translation for Tcl/TK in TASH.

> I updated my system to OS X 10.6.7 and Xcode to 3.2.6.
>
> After downloading c2ada from SVN, rev 23, I cd-ed to the distribution
> directory and built by ./setup and make which created c2ada. I then
> ran c2ada (still cd-ed to the distribution dir) on two very small C
> programs in another directory. The first one
>
> int main(void)
> {
>     int a;
>     a = 1;
>     return 0;
> }
>
> resulted in a useful Ada package. However, the second one
>
> #include <stdio.h>
> int main(void)
> {
>     printf("Hello World\n");
>     return 0;
> }
>
> resulted in just a skeleton Ada package with no useful lines. (Other
> files were also created.) The terminal output had a few lines that
> looked troublesome. I tried with -I/usr/include which is where stdio.h
> is stored but it made no difference in the output, at least with
> respect to the corresponding Ada package.

As the web page http://c2ada.sourceforge.net/c2ada.html says,

   Using C2Ada is a way to lessen the work in translating C headers into
   Ada, to produce a binding, and in translating whole C programs into
   Ada, producing a translation. C2Ada can do about 80% to 90% of the
   work automatically but it still takes some manual work to do the last
   10% or 20%.

   The technology for translating C headers is more mature than the
   technology for translating C functions and statments. C2Ada does not
   translate C++, just C.

Personally I always thought that it was a mistake to take on the
translation of C body files (IYSWIM). I suppose one could make some
simple translations for printf(), but it's not really Ada-compatible.

Re: c2ada bug report filed

[Jerry]

On Apr 4, 10:27 am, Simon Wright <si...@pushface.org> wrote:
> Personally I always thought that it was a mistake to take on the
> translation of C body files (IYSWIM). I suppose one could make some
> simple translations for printf(), but it's not really Ada-compatible.

IDSWYM, even though the docs indicate at least _some_ results--I got
nada. I also tried some .h files as input and also got empty spec
files as output.

Oh well--it was worth a shot. As you say, there might be some project-
specific stuff to play with, but it's not worth the effort given the
size of my project. I do frequently take the option of short-term pain
for long-term gain which is why I originally looked at c2ada several
years ago (when it appeared to be rather dormant), and again now. If I
ever do another binding, I'll look at the conversion utility that is
now included with the AdaCore distribution.

Thanks,
Jerry

Re: c2ada bug report filed

[Per Sandberg]

Just a sugestion using a new GNAT and the coresponding C/C++ compiler

$g++ -c -fdump-ada-spec xx.h

and then you will end up with

   xx_h.ads

I have used this technology to generate bindings for large libraries 
approx 300 C-header-files containing 70000 lines.
And the time to produce a full set of bindings with appropriate names 
and fixes was less then 8 hours.

So i expect c2ada to be obsolete at least when  GNAT GPL 2011 is released.


/Per



On 03/30/2011 10:15 AM, Jerry wrote:
> I made a bug report for c2ada at
> http://sourceforge.net/tracker/?func=detail&aid=3259603&group_id=203517&atid=985906
>
> This isn't  super important but I was going to try to use it to
> convert a 900-line C example file for the PLplot project.
>
> I was trying to build on OS X 10.6.6 and ran into C errors relating to
> undeclared variables.
>
> Jerry

Re: c2ada bug report filed

[Simon Wright]

Per Sandberg <per.sandberg@bredband.net> writes:

> So i expect c2ada to be obsolete at least when GNAT GPL 2011 is
> released.

GNAT GPL 2010 certainly tries; I don't know how good it is.

Just tried on <tcl.h>; GPL 2010 is better than FSF 4.6.0, which didn't
understand
  #define TCL_MAJOR_VERSION 8
for example.

Both made a - to my eyes - strange choice about parameter passing:

   typedef struct Tcl_Interp {
       ...
   } Tcl_Interp;

translated as

   type Tcl_Interp is record
      ...
   end record;
   pragma Convention (C_Pass_By_Copy, Tcl_Interp);

Now, the C code that's being called most certainly doesn't expect
pass-by-copy; and the generated binding always says (eg)

   function Tcl_AppInit (arg1 : access Tcl_Interp) return int;

Wouldn't pragma Convention (C) have done?


For interest, the tcladashell equivalent (which, I believe, was
originally generated using c2ada, but has since been heavily
hand-amended) is

   type Tcl_Interp_Rec (<>) is private;
   type Tcl_Interp is access all Tcl_Interp_Rec;
   pragma Convention (C, Tcl_Interp);

   function Tcl_AppInit (interp : in Tcl_Interp) return C.int;

I shall have a think about this, the 'access' approach is certainly
neat. There's the question of whether null is allowed; if it is, and
customers are using Ada95, 'access' is ruled out.

Re: c2ada bug report filed

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m24o6jovd3.fsf@pushface.org...
...
> I shall have a think about this, the 'access' approach is certainly
> neat. There's the question of whether null is allowed; if it is, and
> customers are using Ada95, 'access' is ruled out.

All anonymous access types in Ada 95 were null excluding; passing "null" to 
them was not allowed. The ARG recommended that all Ada 95 compilers support 
"not null" syntactically (it would have no effect at runtime) in order to 
minimize the incompatibility problems of switching back and forth between 
Ada 95 and Ada 2005. Don't know if that recommendation was adopted widely (I 
believe that Janus/Ada does allow it in Ada 95 mode).

Either "in" or "access" in Ada 95 would not allow null, so if that is 
needed, a named access type has to be used. Ada 2005 would require "not 
null" if null is to be excluded (as noted, Ada 95 compilers are supposed to 
support that, but who knows how many do).

I personally don't like seeing access in any interface that can avoid it. 
But if you need to be able to pass null, you don't have a choice. If not, I 
think "in" is preferred.

                         Randy.

Re: c2ada bug report filed

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:m24o6jovd3.fsf@pushface.org...
> ...
>> I shall have a think about this, the 'access' approach is certainly
>> neat. There's the question of whether null is allowed; if it is, and
>> customers are using Ada95, 'access' is ruled out.
>
> All anonymous access types in Ada 95 were null excluding; passing "null" to 
> them was not allowed. The ARG recommended that all Ada 95 compilers support 
> "not null" syntactically (it would have no effect at runtime) in order to 
> minimize the incompatibility problems of switching back and forth between 
> Ada 95 and Ada 2005. Don't know if that recommendation was adopted widely (I 
> believe that Janus/Ada does allow it in Ada 95 mode).
>
> Either "in" or "access" in Ada 95 would not allow null, so if that is 
> needed, a named access type has to be used. Ada 2005 would require "not 
> null" if null is to be excluded (as noted, Ada 95 compilers are supposed to 
> support that, but who knows how many do).
>
> I personally don't like seeing access in any interface that can avoid it. 
> But if you need to be able to pass null, you don't have a choice. If not, I 
> think "in" is preferred.

It took me a moment to see your point! which is, I think, that (from ARM
B.3) pragma Convention (C) will pass structs and arrays as pointers
anyway. Hmm.

A binding generator will have trouble distinguishing the parameter mode,
of course.