* Import a type from C
@ 2002-11-06 19:48 Francisco Santoyo
2002-11-06 20:06 ` Frank J. Lhota
` (3 more replies)
0 siblings, 4 replies; 13+ messages in thread
From: Francisco Santoyo @ 2002-11-06 19:48 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Import a type from C
2002-11-06 19:48 Import a type from C Francisco Santoyo
@ 2002-11-06 20:06 ` Frank J. Lhota
2002-11-06 23:10 ` Stephen Leake
2002-11-07 7:16 ` Victor Porton
` (2 subsequent siblings)
3 siblings, 1 reply; 13+ messages in thread
From: Frank J. Lhota @ 2002-11-06 20:06 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Import a type from C
2002-11-06 20:06 ` Frank J. Lhota
@ 2002-11-06 23:10 ` Stephen Leake
2003-01-08 20:46 ` Rupert Pigott
0 siblings, 1 reply; 13+ messages in thread
From: Stephen Leake @ 2002-11-06 23:10 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Import a type from C
2002-11-06 19:48 Import a type from C Francisco Santoyo
2002-11-06 20:06 ` Frank J. Lhota
@ 2002-11-07 7:16 ` Victor Porton
2002-11-07 13:47 ` Stephen Leake
2002-11-07 16:03 ` Frank J. Lhota
2002-11-07 19:00 ` chris.danx
2002-11-08 4:02 ` Victor Porton
3 siblings, 2 replies; 13+ messages in thread
From: Victor Porton @ 2002-11-07 7:16 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Import a type from C
2002-11-07 7:16 ` Victor Porton
@ 2002-11-07 13:47 ` Stephen Leake
2002-11-07 16:03 ` Frank J. Lhota
1 sibling, 0 replies; 13+ messages in thread
From: Stephen Leake @ 2002-11-07 13:47 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Import a type from C
2002-11-07 7:16 ` Victor Porton
2002-11-07 13:47 ` Stephen Leake
@ 2002-11-07 16:03 ` Frank J. Lhota
2002-11-07 16:20 ` Robert A Duff
1 sibling, 1 reply; 13+ messages in thread
From: Frank J. Lhota @ 2002-11-07 16:03 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Import a type from C
2002-11-07 16:03 ` Frank J. Lhota
@ 2002-11-07 16:20 ` Robert A Duff
2002-11-08 14:51 ` Stephen Leake
0 siblings, 1 reply; 13+ messages in thread
From: Robert A Duff @ 2002-11-07 16:20 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Import a type from C
2002-11-06 19:48 Import a type from C Francisco Santoyo
2002-11-06 20:06 ` Frank J. Lhota
2002-11-07 7:16 ` Victor Porton
@ 2002-11-07 19:00 ` chris.danx
2002-11-08 4:02 ` Victor Porton
3 siblings, 0 replies; 13+ messages in thread
From: chris.danx @ 2002-11-07 19:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Import a type from C
2002-11-06 19:48 Import a type from C Francisco Santoyo
` (2 preceding siblings ...)
2002-11-07 19:00 ` chris.danx
@ 2002-11-08 4:02 ` Victor Porton
3 siblings, 0 replies; 13+ messages in thread
From: Victor Porton @ 2002-11-08 4:02 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Import a type from C
2002-11-07 16:20 ` Robert A Duff
@ 2002-11-08 14:51 ` Stephen Leake
0 siblings, 0 replies; 13+ messages in thread
From: Stephen Leake @ 2002-11-08 14:51 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Import a type from C
2002-11-06 23:10 ` Stephen Leake
@ 2003-01-08 20:46 ` Rupert Pigott
2003-01-10 3:48 ` Eric G. Miller
2003-01-14 4:47 ` David Thompson
0 siblings, 2 replies; 13+ messages in thread
From: Rupert Pigott @ 2003-01-08 20:46 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Import a type from C
2003-01-08 20:46 ` Rupert Pigott
@ 2003-01-10 3:48 ` Eric G. Miller
2003-01-14 4:47 ` David Thompson
1 sibling, 0 replies; 13+ messages in thread
From: Eric G. Miller @ 2003-01-10 3:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Import a type from C
2003-01-08 20:46 ` Rupert Pigott
2003-01-10 3:48 ` Eric G. Miller
@ 2003-01-14 4:47 ` David Thompson
1 sibling, 0 replies; 13+ messages in thread
From: David Thompson @ 2003-01-14 4:47 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2003-01-14 4:47 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-11-06 19:48 Import a type from C Francisco Santoyo
2002-11-06 20:06 ` Frank J. Lhota
2002-11-06 23:10 ` Stephen Leake
2003-01-08 20:46 ` Rupert Pigott
2003-01-10 3:48 ` Eric G. Miller
2003-01-14 4:47 ` David Thompson
2002-11-07 7:16 ` Victor Porton
2002-11-07 13:47 ` Stephen Leake
2002-11-07 16:03 ` Frank J. Lhota
2002-11-07 16:20 ` Robert A Duff
2002-11-08 14:51 ` Stephen Leake
2002-11-07 19:00 ` chris.danx
2002-11-08 4:02 ` Victor Porton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox