At 02:44 AM 10/16/98 -0700, Mr Ada wrote:
>I am getting this error from GNAT and it is puzzling me a
>bit.

   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;
with System;
procedure Word_Size is
begin
  Put_Line(" System.Storage_Unit is " & Integer'Image(System.Storage_Unit));
  Put_Line(" System.Word_Size    is " & Integer'Image(System.Word_Size));
end Word_Size;

    With gnat 3.10p on Windows NT on a Pentium Pro I get:

word_size
 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
this feature.

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...