Import a type from C

Import a type from C

[Francisco Santoyo]

Hi

I have to use a type struct, which is defined in a C library. Anybody know, 
how can I import that type from C to Ada?

Thanks.

Re: Import a type from C

[Frank J. Lhota]

A C struct is basically the equivalent to an Ada record type, so if the C
type is declared as

    typedef struct tag_my_data {
        ...
        } my_data;


I would declare an Ada record type for that C struct, e.g..

    type My_Data is
        record
            ...
        end record;
    pragma Convention( C, My_Data );

The Convention pragma can be used to specify that this record type should be
laid out in the same way that a C compiler would. Also, check out the
Interfaces.C package. It defines types that correspond to C scalar types.
You should use this to declare the scalar components in the Ada equivalent
of the C struct.

If the type contains a C union, look up the Unchecked_Union pragma to see
how to write an equivalent Ada record type.

Re: Import a type from C

[Stephen Leake]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:

>     pragma Convention( C, My_Data );
> 
> The Convention pragma can be used to specify that this record type should be
> laid out in the same way that a C compiler would. 

Note that "a C compiler" really means "the C compiler that the Ada
compiler knows about, with its default command line args". For
example, GNAT will assume Gnu C, _without_ -fpacked. ObjectAda
probably assumes MS C, again without the "packed" flag. That has
caused me some major problems, when linking against C code compiled
_with_ the -fpacked flag.

So I always use a rep spec, instead of relying on Convention (C). Then
I write some C code that checks the struct size, to be sure there is
no padding.

-- 
-- Stephe

Re: Import a type from C

[Rupert Pigott]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:u7kfqjnvv.fsf@gsfc.nasa.gov...
> "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:
>
> >     pragma Convention( C, My_Data );
> >
> > The Convention pragma can be used to specify that this record type
should be
> > laid out in the same way that a C compiler would.
>
> Note that "a C compiler" really means "the C compiler that the Ada
> compiler knows about, with its default command line args". For
> example, GNAT will assume Gnu C, _without_ -fpacked. ObjectAda
> probably assumes MS C, again without the "packed" flag. That has
> caused me some major problems, when linking against C code compiled
> _with_ the -fpacked flag.
>
> So I always use a rep spec, instead of relying on Convention (C). Then
> I write some C code that checks the struct size, to be sure there is
> no padding.

Perhaps I'm overly pessimistic here... IIRC there is no guarantee
of the order of members within a structure in C either. One of those
little gotchas (along with no alignment control) that **** portable
code and force you to go the long way around...

Cheers,
Rupert

Re: Import a type from C

[Eric G. Miller]

Rupert Pigott wrote:
> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:u7kfqjnvv.fsf@gsfc.nasa.gov...
> 
>>"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:
>>
>>
>>>    pragma Convention( C, My_Data );
>>>
>>>The Convention pragma can be used to specify that this record type
> 
> should be
> 
>>>laid out in the same way that a C compiler would.
>>
>>Note that "a C compiler" really means "the C compiler that the Ada
>>compiler knows about, with its default command line args". For
>>example, GNAT will assume Gnu C, _without_ -fpacked. ObjectAda
>>probably assumes MS C, again without the "packed" flag. That has
>>caused me some major problems, when linking against C code compiled
>>_with_ the -fpacked flag.
>>
>>So I always use a rep spec, instead of relying on Convention (C). Then
>>I write some C code that checks the struct size, to be sure there is
>>no padding.
> 
> 
> Perhaps I'm overly pessimistic here... IIRC there is no guarantee
> of the order of members within a structure in C either. One of those
> little gotchas (along with no alignment control) that **** portable
> code and force you to go the long way around...

You're high 8^)  The order of members in a C struct is always as specified
in the definition.  Furthermore, a pointer to a struct is always
guaranteed to resolve to a pointer to the first member.  The alignment
of any subsequent members is implementation defined.  Portable C code
would never pack a struct to begin with (an inherently unportable practice).

-- 
echo ">gra.fcw@2ztr< eryyvZ .T pveR" | rot13 | reverse

Re: Import a type from C

[David Thompson]

08
Rupert Pigott <darkboo-remove-this-ng.@hotmail.com> wrote :
> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:u7kfqjnvv.fsf@gsfc.nasa.gov...
...
> > Note that [Convention(C,] really means "the C compiler that the Ada
> > compiler knows about, with its default command line args". ...
> > So I always use a rep spec, instead of relying on Convention (C). Then
> > I write some C code that checks the struct size, to be sure there is
> > no padding.
>
> Perhaps I'm overly pessimistic here... IIRC there is no guarantee
> of the order of members within a structure in C either. One of those
> little gotchas (along with no alignment control) that **** portable
> code and force you to go the long way around...
>
In C there is except only partly for bitfields.  Which of course you
may be using if you try (unsuccessfully) to fully specify a record.
C90 6.5.2.1 and C99 6.7.2.1p10,12,13,15 [bracketed text deleted]
An implementation may allocate any addressable storage unit large enough to hold
a bit-field. If enough space remains, a bit-field that immediately follows
another bit-field in a
structure shall be packed into adjacent bits of the same unit. If insufficient
space remains,
whether a bit-field that does not fit is put into the next unit or overlaps
adjacent units is
implementation-defined. The order of allocation of bit-fields within a unit
(high-order to
low-order or low-order to high-order) is implementation-defined. The alignment
of the
addressable storage unit is unspecified.
...
Each non-bit-field member of a structure or union object is aligned in an
implementation-defined
manner appropriate to its type.
Within a structure object, the non-bit-field members and the units in which
bit-fields
reside have addresses that increase in the order in which they are declared. ...
There may [therefore] be unnamed
padding within a structure object, but not at its beginning.
...
There may be unnamed padding at the end of a structure or union[, as necessary
to achieve the approriate alignment...].

In C++98 the corresponding requirement is partially relaxed.
9.2[class.mem]p12:
Nonstatic data members of a (non-union) class declared without
an intervening access-specifier are allocated so that later members
have higher addresses within a class object.  The order of allocation
of nonstatic data members separated by an access-specifier is
unspecified (11.1).  Implementation alignment requirements might
cause two adjacent members not to be allocated immediately
after each other; so might requirements for [vptrs].
9.6[class.bit]p1:
A member-declarator of the form ... specifies a bit-field ....
Allocation of bit-fields within a class object is implementation-defined.
Alignment of bit-fields is implementation-defined.  ....
p3:  The address-of operator & shall not be applied to a bit-field ....
A non-const reference shall not be bound to a bit-field. ....

The address ordering is redundantly specified in 5.9[expr.rel]p2.
Note that in C++ (standard) terminology, 'class' subsumes 'struct'
and 'union' except where excluded, and 'nonstatic' members of a
class are those that exist in each instance (data/variable) or apply
to a given instance (function/method) using the magic 'this'.
(And like Ada, in both C and C++, 'implementation-defined'
must be documented but 'unspecified' need not.)

--
- David.Thompson 1 now at worldnet.att.net

Re: Import a type from C

[Victor Porton]

In article <u7kfqjnvv.fsf@gsfc.nasa.gov>,
	Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:
> 
>>     pragma Convention( C, My_Data );
> 
> Note that "a C compiler" really means "the C compiler that the Ada
> compiler knows about, with its default command line args". For
> example, GNAT will assume Gnu C, _without_ -fpacked. ObjectAda
> probably assumes MS C, again without the "packed" flag. That has
> caused me some major problems, when linking against C code compiled
> _with_ the -fpacked flag.

May be specifying both

pragma Convention( C, My_Data );
and
pragma Pack( My_Type );

will be compatible with gcc -fpacked?

Re: Import a type from C

[Stephen Leake]

porton@ex-code.com (Victor Porton) writes:

> May be specifying both
> 
> pragma Convention( C, My_Data );
> and
> pragma Pack( My_Type );
> 
> will be compatible with gcc -fpacked?

Well, it might, but the standard doesn't say. Actually, I would hope
the compiler would reject this, since it is asking for conflicting
things. 

I guess my real point is that the standard does _not_ clearly state
what Convention (C, ...) really means (it is entirely implementation
dependent), so I can't rely on it.

Ada is supposed to be easy to _read_, not necessarily easy to _write_.
Convention (C) is just a shortcut for the proper rep clause.

Hmm. I guess if you have two Ada compilers, and two corresponding C
compilers, and you use the correct command line flags on the C
compilers, and the corresponding rep clauses are different, then
Convention C is a better alternative than gnatprep to choose the
representation. However, in my experience, I end up needing gnatprep
(for other reasons) in a situation like that anyway.

-- 
-- Stephe

Re: Import a type from C

[Frank J. Lhota]

Thinking over my previous experience with this type of work, I would go with
the advice of using a representation clause. In general, a representation
clause should be used whenever a type cooresponds to data external to the
Ada program. This eliminates any concern about how this or that compiler
lays out a record.

Ada programmers are blessed with the whole chapter 13 support. C / C++ has
only the crude pack pragma / command line option to control the layout of a
struct. Is there any C compiler that automatically generates a decription of
how it lays out a struct? If I declare

    typedef struct tag_mydata {
        char     lead;
        long     total;
        unsigned year  : 12;
        unsigned month :  4;
        unsigned day   :  5;
        } mydata;

is there a C compiler that has a command line option that will generate a
listing that shows the byte offset of the total member from the start of a
"mydata" struct, or the location of the bits that make up the month member?
Neither gcc nor MSVC++ has such an option, which would make this work much
easier.

Re: Import a type from C

[Robert A Duff]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:

> ...only the crude pack pragma / command line option ...

What's the "pack pragma".  Is this standard C, or something supported by
some C compilers?  (Which compilers?)

What does it do?  E.g., does it work for arrays?  (It's hard to see how
it could, given C's confusion between arrays and pointers.)

- Bob

Re: Import a type from C

[Stephen Leake]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:
> 
> > ...only the crude pack pragma / command line option ...
> 
> What's the "pack pragma".  Is this standard C, or something supported by
> some C compilers?  (Which compilers?)

gcc supports "__attribute__ ((packed))". It applies to structs, or
fields within structs (not arrays).

I'm on a flight project that has a lot of inherited C code, and some
new Ada code (all by me). The previous project used -fpacked command
line flag for all the C code. But we are also switching operating
systems, and the new one can't tolerate -fpacked. So we have to add
__attribute__ ((packed)) all over the place. But some people want to
run unit tests using Microsoft Visual C (why, I'm not sure :). So we
use a #define to get rid of the __attribute__.

I keep saying "see how much easier this is in Ada". Some of them are
beginning to hear it :).

-- 
-- Stephe

Re: Import a type from C

[chris.danx]

Francisco Santoyo wrote:

 > Hi
 >
 > I have to use a type struct, which is defined in a C library. Anybody
 > know,
 > how can I import that type from C to Ada?
 >
 > Thanks.


As far as I'm aware you can't import a "type", but you can declare an
equivalent type and import variables of that type into Ada.  i.e. you
can't import the type X, only variables of type X.

struct myStruct {
    int x;
    int y;
    char *str;
};

would go to an Ada record

type myStruct is record
     x : integer;
     y : integer;
     str : blah -- haven't done this in a while.
end record;


The details are a little sketchy as I've been programming in Java for
two, maybe three months now (my knowlege of Ada is evaporating :( ), but
structs in C rougly correspond to records in Ada, C strings to Char_Ptr,
etc.  Of course, some of this depends on the compilers involved too, so
there's some variation.

What I would be inclined to do in the case of Strings would be to
convert C strings to proper Ada Strings, if I was going to use them in
Ada code and no more in C code (if you need to send them back, you have
to consider a tradeoff between the convienance of Ada strings and the
conversion between the two forms - which costs time).

The lovelace tutorial has some text on interfacing with C, which maybe
worth a look (it's a much better description than my pitiful attempt, so
you *should* read it to unconfuse yourself after reading my post :)  I
have a habit of doing stuff like that).  There's a link to it from
www.adapower.com iirc.


hth,
Danx
-- 
for personal replies change spamoff to chris

Re: Import a type from C

[Victor Porton]

In article <wcclm45jqrw.fsf@shell01.theworld.com>,
	Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:
> 
>> ...only the crude pack pragma / command line option ...
> 
> What's the "pack pragma".  Is this standard C, or something supported by
> some C compilers?  (Which compilers?)

It is a non-standard thing varying by compilers...