Re: Ada records and byte order

[Carbonne Damien <damien.carbonne@free.fr>]

Karl Ran a �crit :

>
> Here is the code ...
>
> procedure test is
>
>    subtype BYTE     is Integer range 0 .. 2 **   8 - 1;

Add:
for BYTE'size use 8;

>
>    subtype WORD12   is integer range 0 .. 2 **  12 - 1;

Add
for WORD'Size use 12;

>
>    subtype WORD4    is integer range 0 .. 2 **   4 - 1;

Add:
for WORD4'Size use 4;

>
>
>    type My_rec is
>       record
>          A : BYTE;
>          B : WORD12;
>          C : WORD4;
>       end record;
>
>    for My_rec use
>       record
>          A at 0 range 0 ..  7;
>          B at 1 range 0 .. 11;
>          C at 2 range 0 ..  3;

Change previous line to:
C at 1 range 12 .. 15;
or
C at 2 range 4 .. 7;

>
>       end record;

Add:
for My_rec'Size use 24;

>
>
>    Abc : My_Rec;
>
> begin
>    Abc.b := 16#123#;
>    ...
> end test;
>
> ... which fails to compile whith GNAT on a (low-endian) i386:
> test.adb:31:10: component "C" overlaps "B" at line 30
>

The message seems quite explicit here !

>
> Is there an Ada like (TM) solution for this kind of (byte order) problem?

What you have is not a byte order problem.
You may have one if the program with which you wrote the file and the one you
are
writing in Ada are run on targets with different byte orders.
This can not be deduced from your message.

For Byte order problem, I remember having seen something (quite complexe) on
this thread some times ago, but I don't remember when and who posted it.

Anyway,  a compiler may refuse certain representation clauses and thus, there
may be some portability problems in this area.
GNAT should accept what you want in that case, unless there is a real error like
here.
Pragmatically, from what I have read on thsi subject, major compilers accept
standard size clauses (powers of 2). There are always limits !

The Ada syntax is different from C/C++ one for bitfields where you only specify
the size (length) of each field, whereas in Ada you specify
bit bounds (first and last) counted from an offset (defined in Memory_Unit I
think).


Regards

Damien