Help: Storage size

Help: Storage size

[Adrian Hoe]

If I have a C code like this:

typedef unsigned short   CARD16;

and

typedef struct {
   CARD8     reqType;
   CARD16    length : 16;
} tReq;

How can the above struct (record) be implemented in Ada?

Where CARD16 is define as follow in Ada:

type CARD16 is new X.Unsigned_Short;


Can anyone please help?
--
Adrian BY, Hoe
--------------


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Help: Storage size

[David C. Hoos, Sr.]

Adrian Hoe wrote in message <7mejue$9lk$1@nnrp1.deja.com>...
>If I have a C code like this:
>
>typedef unsigned short   CARD16;
>
>and
>
>typedef struct {
>   CARD8     reqType;
>   CARD16    length : 16;
>} tReq;
>
>How can the above struct (record) be implemented in Ada?
>
>Where CARD16 is define as follow in Ada:
>
>type CARD16 is new X.Unsigned_Short;
>
>
>Can anyone please help?
>--
Several problems here -- e.g.:

1. Where is the declaration for CARD8?  This will affect the result.

2. If #pragma pack is used, this will affect the result.

3. If unsigned short is 16 bits on your system, the bit-field
   specification (:16) would appear to be redundant.

4. Where is the declaration for X.Unsigned_Short?

5. Bit-field implementations are compiler-dependent, so from
   the code you supplied (without any compiler or platform
   identification) it is impossible to say for sure what is
   the memory layout of the tReq struct.

If the memory layout of the C struct is known, writing the
Ada declaration is trivial.

Re: Help: Storage size

[Adrian Hoe]

In article <7mf7lp$c9g@hobbes.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
>
> Adrian Hoe wrote in message <7mejue$9lk$1@nnrp1.deja.com>...
> >If I have a C code like this:
> >
> >typedef unsigned short   CARD16;
> >
> >and
> >
> >typedef struct {
> >   CARD8     reqType;
> >   CARD16    length : 16;
> >} tReq;
> >
> >How can the above struct (record) be implemented in Ada?
> >
> >Where CARD16 is define as follow in Ada:
> >
> >type CARD16 is new X.Unsigned_Short;
> >
> >
> >Can anyone please help?
> >--
> Several problems here -- e.g.:
>
> 1. Where is the declaration for CARD8?  This will affect the result.

CARD8 is declare as unsigned char;



> 2. If #pragma pack is used, this will affect the result.

#pragma pack is not used.



> 3. If unsigned short is 16 bits on your system, the bit-field
>    specification (:16) would appear to be redundant.

Most platforms have 16 bits for unsigned short. The bit-field
specification (e.g. :16) is used to ensure 16 bits mapping on other
platform(s).



> 4. Where is the declaration for X.Unsigned_Short?

In X.ads, it is declare as

	subtype unsigned_short is interfaces.c.unsigned_short;



> 5. Bit-field implementations are compiler-dependent, so from
>    the code you supplied (without any compiler or platform
>    identification) it is impossible to say for sure what is
>    the memory layout of the tReq struct.

I am using GNAT for Linux (PC) and intend to target the code to other
platforms like Sun and Alpha.



> If the memory layout of the C struct is known, writing the
> Ada declaration is trivial.
>
>


Let's assume the bit-field specification (:16 e.g.) is needed badly, how
can I implement the C's struct in Ada?
--
Adrian BY, Hoe
--------------


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Help: Storage size

[David C. Hoos, Sr.]

Adrian Hoe wrote in message <7mfndb$mc8$1@nnrp1.deja.com>...
>In article <7mf7lp$c9g@hobbes.crc.com>,
>  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
>>
>> Adrian Hoe wrote in message <7mejue$9lk$1@nnrp1.deja.com>...
>> >If I have a C code like this:
>> >
>> >typedef unsigned short   CARD16;
>> >
>> >and
>> >
>> >typedef struct {
>> >   CARD8     reqType;
>> >   CARD16    length : 16;
>> >} tReq;
>> >
>> >How can the above struct (record) be implemented in Ada?
>> >
>> >Where CARD16 is define as follow in Ada:
>> >
>> >type CARD16 is new X.Unsigned_Short;
>> >
>> >
>> >Can anyone please help?
>> >--
>> Several problems here -- e.g.:
>>
>> 1. Where is the declaration for CARD8?  This will affect the result.
>
>CARD8 is declare as unsigned char;
>
>
>
>> 2. If #pragma pack is used, this will affect the result.
>
>#pragma pack is not used.
>
>
>
>> 3. If unsigned short is 16 bits on your system, the bit-field
>>    specification (:16) would appear to be redundant.
>
>Most platforms have 16 bits for unsigned short. The bit-field
>specification (e.g. :16) is used to ensure 16 bits mapping on other
>platform(s).
>
>
>
>> 4. Where is the declaration for X.Unsigned_Short?
>
>In X.ads, it is declare as
>
> subtype unsigned_short is interfaces.c.unsigned_short;
>
>
>
>> 5. Bit-field implementations are compiler-dependent, so from
>>    the code you supplied (without any compiler or platform
>>    identification) it is impossible to say for sure what is
>>    the memory layout of the tReq struct.
>
>I am using GNAT for Linux (PC) and intend to target the code to other
>platforms like Sun and Alpha.
>
>
>
>> If the memory layout of the C struct is known, writing the
>> Ada declaration is trivial.
>>
>>
>
>
>Let's assume the bit-field specification (:16 e.g.) is needed badly, how
>can I implement the C's struct in Ada?
>--

If you want to be assured that your types have the correct size,
then I would not recommend basing your types on
Interfaces.C.Unsigned_Short, because that type is dependent on the size
of C's unsigned short type for that platform.

How about starting from scratch -- e.g.:

   type Card8 is mod 2 ** 8;
   for Card8'size use 8;
   type Card16 is mod 2 ** 16;
   for Card16'size use 16;

   type Treq is record
      ReqType : Card8;
      Length  : Card16;
   end record;

   for Treq use record
      ReqType at 0 range 0 .. 7;
      Length  at 2 range 0 .. 15;
   end record;

   for Treq'size use 32;

Note that there is one byte of unocupied space between the
record components, consistent with the way gcc lays out
your struct, in the absence of #pragma pack.

Hope this helps.

Re: Help: Storage size

[Adrian Hoe]

In article <7mfs92$jch@hobbes.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
>
> Adrian Hoe wrote in message <7mfndb$mc8$1@nnrp1.deja.com>...
> >In article <7mf7lp$c9g@hobbes.crc.com>,
> >  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
> >>
> >> Adrian Hoe wrote in message <7mejue$9lk$1@nnrp1.deja.com>...
> >> >If I have a C code like this:
> >> >
> >> >typedef unsigned short   CARD16;
> >> >
> >> >and
> >> >
> >> >typedef struct {
> >> >   CARD8     reqType;
> >> >   CARD16    length : 16;
> >> >} tReq;
> >> >
> >> >How can the above struct (record) be implemented in Ada?
> >> >
> >> >Where CARD16 is define as follow in Ada:
> >> >
> >> >type CARD16 is new X.Unsigned_Short;
> >> >
> >> >
> >> >Can anyone please help?
> >> >--
> >> Several problems here -- e.g.:
> >>
> >> 1. Where is the declaration for CARD8?  This will affect the
result.
> >
> >CARD8 is declare as unsigned char;
> >
> >
> >
> >> 2. If #pragma pack is used, this will affect the result.
> >
> >#pragma pack is not used.
> >
> >
> >
> >> 3. If unsigned short is 16 bits on your system, the bit-field
> >>    specification (:16) would appear to be redundant.
> >
> >Most platforms have 16 bits for unsigned short. The bit-field
> >specification (e.g. :16) is used to ensure 16 bits mapping on other
> >platform(s).
> >
> >
> >
> >> 4. Where is the declaration for X.Unsigned_Short?
> >
> >In X.ads, it is declare as
> >
> > subtype unsigned_short is interfaces.c.unsigned_short;
> >
> >
> >
> >> 5. Bit-field implementations are compiler-dependent, so from
> >>    the code you supplied (without any compiler or platform
> >>    identification) it is impossible to say for sure what is
> >>    the memory layout of the tReq struct.
> >
> >I am using GNAT for Linux (PC) and intend to target the code to other
> >platforms like Sun and Alpha.
> >
> >
> >
> >> If the memory layout of the C struct is known, writing the
> >> Ada declaration is trivial.
> >>
> >>
> >
> >
> >Let's assume the bit-field specification (:16 e.g.) is needed badly,
how
> >can I implement the C's struct in Ada?
> >--
>
> If you want to be assured that your types have the correct size,
> then I would not recommend basing your types on
> Interfaces.C.Unsigned_Short, because that type is dependent on the
size
> of C's unsigned short type for that platform.
>
> How about starting from scratch -- e.g.:
>
>    type Card8 is mod 2 ** 8;
>    for Card8'size use 8;
>    type Card16 is mod 2 ** 16;
>    for Card16'size use 16;
>
>    type Treq is record
>       ReqType : Card8;
>       Length  : Card16;
>    end record;
>
>    for Treq use record
>       ReqType at 0 range 0 .. 7;
>       Length  at 2 range 0 .. 15;
>    end record;
>
>    for Treq'size use 32;
>
> Note that there is one byte of unocupied space between the
> record components, consistent with the way gcc lays out
> your struct, in the absence of #pragma pack.
>
> Hope this helps.
>
>



This method gives the most assurance in plain Ada context. But, what if
the intention to interface from Ada to the original (assumed) C's
struct? Is this method applicable in this context (Interfacing to C)?
--
Adrian BY, Hoe
--------------


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Help: Storage size

[Simon Wright]

Adrian Hoe <byhoe@my-deja.com> writes:

> This method gives the most assurance in plain Ada context. But, what
> if the intention to interface from Ada to the original (assumed) C's
> struct? Is this method applicable in this context (Interfacing to
> C)?

If you are interfacing to C then you should definitely use the types
in Interfaces.C. But I thought you said earlier that you had :16 in a
struct in case the platform's unsigned_short wasn't 16 bits???

You really need to go back to see how CARD16 is defined, I think.

IIRC, you are looking at Xlib stuff -- almost certainly this will be
in terms of C types. X protocol stuff, now that's different ..

In X, you're much more likely to have portability trouble with long,
in my experience. Also endianness.

Do you really have to implement your own bindings? I'm sure there are
some free ones out there .. try adahome ..

Re: Help: Storage size

[Adrian Hoe]

In article <x7vyagjdmsl.fsf@pogner.moho>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:

> IIRC, you are looking at Xlib stuff -- almost certainly this will be
> in terms of C types. X protocol stuff, now that's different ..

Yes, I am looking at X protocol stuff..



> In X, you're much more likely to have portability trouble with long,
> in my experience. Also endianness.
>
> Do you really have to implement your own bindings? I'm sure there are
> some free ones out there .. try adahome ..
>

Yes, I have to implement some of the binding myself. The AdaXlibXt
binding from AdaHome is not complete and is target to Sun/VADS etc..

My current intended target is Linux (PC).
--
Adrian BY, Hoe
--------------


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Help: Storage size

[Adrian Hoe]

In article <7mfs92$jch@hobbes.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
>
> If you want to be assured that your types have the correct size,
> then I would not recommend basing your types on
> Interfaces.C.Unsigned_Short, because that type is dependent on the
size
> of C's unsigned short type for that platform.
>
> How about starting from scratch -- e.g.:
>
>    type Card8 is mod 2 ** 8;
>    for Card8'size use 8;
>    type Card16 is mod 2 ** 16;
>    for Card16'size use 16;
>
>    type Treq is record
>       ReqType : Card8;
>       Length  : Card16;
>    end record;
>
>    for Treq use record
>       ReqType at 0 range 0 .. 7;
>       Length  at 2 range 0 .. 15;
>    end record;
>
>    for Treq'size use 32;
>
> Note that there is one byte of unocupied space between the
> record components, consistent with the way gcc lays out
> your struct, in the absence of #pragma pack.


In case of the above implementation, how can one determine  the one
unoccupied byte between the two record components? Is this compiler or
platform dependable? In such cases, what will happen to the following
implementation:

   type Card8 is mod 2 ** 8;
   for Card8'size use 8;
   type Card16 is mod 2 ** 16;
   for Card16'size use 16;

   type Int32 is range -2 ** 31 .. (2 ** 31) - 1;
   for Int32'Size use 32;
   subtype Long is Int32;

   type Float64 is digits 15;
   subtype Long_Flt is Float64;

   Word_Size : constant POSITIVE := Long'Size / 8;

   type TReq is
      record
         ReqType  : Card8;
         Length   : Card16;
         Distance : Long_Flt;
      end record;

   for TReq use
      record
         ReqType  at 0 * Word_Size     range 0 .. 7;
         Length   at 0 * Word_Size + 2 range 0 .. 15
         Distance at 2 * Word_Size     range 0 .. 63;
      end record;


There will be one unoccupied byte between ReqType and Length and 4
unoccupied byte between Length and Distance. The record will be padded
to 32-bit spaces. Is this correct?

If Yes, is this portable to 64-bit platform such as UltraSPARC? Or in
the case of UltraSPARC, the record will be padded to 64-bit space?
--
Adrian BY, Hoe
--------------


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Help: Storage size

[Keith Thompson]

Adrian Hoe <byhoe@my-deja.com> writes:
> In article <7mf7lp$c9g@hobbes.crc.com>,
>   "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
[...]
> > 3. If unsigned short is 16 bits on your system, the bit-field
> >    specification (:16) would appear to be redundant.
> 
> Most platforms have 16 bits for unsigned short. The bit-field
> specification (e.g. :16) is used to ensure 16 bits mapping on other
> platform(s).

In purely C terms, this is a bad idea.  The C standard allows a
bit-field to be of type int, signed int, or unsigned int (in this
context only, it's implementation-defined whether a plain "int"
is signed or unsigned).  Thus an unsigned short bit-field is,
strictly speaking, illegal -- though many (most?) implementations
will accept it as an extension.  (Try compiling your C source with
"gcc -ansi -pedantic -Wall".)  Many other aspects of bit-fields are
either implementation-defined or unspecified.

If you want a C integer type of a specified width, it's usually best
to declare it as a typedef whose definition varies from one system
to another.  C9X, the next revision of the C standard, will provide
such typedefs in the new predefined header <stdint.h>, but you can
easily roll your own.  Part of the job of porting your code to another
architecture is then updating the typedefs.  (Be sure to include some
automated checking code to make sure you got it right.)

Once you've done this, matching the C integer types to corresponding
Ada types is pretty easy.  For example, an Ada 16-bit unsigned type
can be declared as:

    type Unsigned_16 is mod 2**16;
    for Unsigned_16'Size use 16;

The exact layout of record components / struct members is
implementation-defined in both languages.  Using pragma Convention(C)
on the Ada side should guarantee that they match.

The only real drawback of this approach is that not all platforms
actually have a 16-bit integer type.  In the unlikely event that this
becomes an issue (for example, on some Crays), I suppose you can
always fall back to bit-fields.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
One of the great tragedies of ancient history is that Helen of Troy
lived before the invention of the champagne bottle.