At 02:44 AM 10/16/98 -0700, Mr Ada wrote:
>I am getting this error from GNAT and it is puzzling me a
On which OS and hardware?
>Can't we use this attribute to set up a record as big/little
>endian as needed? If I was transferring data from a big
>endian machine to a little endian machine wouldn't this
>attribute help me from do data marshalling?
Yes, and yes. But read the implementation advice: "If Word_Size =
Storage_Unit, then the implementation should support the nondefault bit
ordering in addition to the default bit ordering." Now run this program:
with Ada.Text_IO; use Ada.Text_IO;
procedure Word_Size is
Put_Line(" System.Storage_Unit is " & Integer'Image(System.Storage_Unit));
Put_Line(" System.Word_Size is " & Integer'Image(System.Word_Size));
With gnat 3.10p on Windows NT on a Pentium Pro I get:
System.Storage_Unit is 8
System.Word_Size is 32
The rejection of the non-standard bit order when I try to compile your
program is expected.
So why have the attribute if attribute clauses might not be useful?
Because the attribute clauses are very useful. They tell you (by rejecting
the program) that the bit ordering requested can't be supported. This
issue was discussed at length and the consensus was that requiring
implementations to store values in non-contiguous fields was not worth the
agony. Of course, you can always pay a vendor to add it if you really need
Robert I. Eachus
function Message (Text: in Clever_Ideas) return Better_Ideas is...