Re: Flags in Ada?

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <SPIEGEL.94Oct25113657@berlin.bruessel.informatik.uni-stuttgart.de>, spiegel@bruessel.informatik.uni-stuttgart.de (Andre Spiegel) writes: 

|>                       how would I go about representing *flags* --
|> i.e. words, in which the individual bits have names, and can be set,
|> cleared, or'ed, xor'ed, and the like?
|>
|> I seem to recall that all of this is realized very comfortably in Ada
|> 9X, but how can I do it in Ada 83?

   type Permission_Type is
      (Owner_Read, Owner_Write, Owner_Execute,
       Group_Read, Group_Write, Group_Execute,
       World_Read, World_Write, World_Execute);

      -- These are the "bit names"

   type Permission_Set_Type is array (Permission) of Boolean;
   pragma Pack (Permission_Set_Type);

      -- This is the "word"

   Default_Permissions : constant Permission_Set_Type :=
                           Permission_Set_Type'
                              (Owner_Read .. Owner_Execute => True,
                               Group_Read | World_Read     => True,
                               others                      => False);

      -- This is the use of an array aggregate to specify a "word" value.

   Current_Permissions : Permission_Set_Type := (Permission_Type => False);

   Current_Permissions(World_Execute) := True;

   if Current_Permissions(World_Write) then
      Clobber_File;
   end if;

      -- These are uses of indexed components to set and examine
      --    individual "bits"

   Current_Positions := Current_Positions or Default_Positions;

      -- This is the application of logical operators to arrays of
      --    Boolean values.  and, or, xor, and not can be used in this
      --    way and they apply bit by bit.

|> Another question: UNIX returns a pointer to some data structure, which
|> I want to read and possibly modify from within Ada. What would be the
|> adequate way to do this? Off the cuff, I can think of two
|> possibilities: 
|>
|>   (1) declare the operating system routine to be returning an access
|>       value, pointing to an Ada record, which resembles the C
|>       structure.
...
|>       Disadvantage: As far as I know, access types do not necessarily
|>       have to be implemented as pointers. I have read (recently in
|>       this group), that GNAT, for example, doesn't always do that.
|>       Also, the Sparc Alsys compiler (which I'm using) seems to use
|>       the numeric address *one* to indicate a null access value...

Correct.  It's elegant when it works, but not very portable.

|>   (2) declare the operating system routine to be returning
|>       System.Address, and use an address clause to interpret the
|>       memory area pointed to as the corresponding structure.
|>
|>         function OS_Routine (...) return System.Address;
|>
|>         Data_Pointer : System.Address;
|>
|>      ...
|>
|>         Data_Pointer := OS_Routine (...);
|>
|>         -- check for null address here, using Unchecked_Conversion
|>         -- to convert Data_Pointer to Integer?
|>
|>      declare
|>           Result : Data;
|>        for Result use at Data_Pointer;
|>         begin
|>           -- process Result...
|>         end;
|>
|>       Questions: Is this acceptable?

Yes, this is the right way to do this.

|>                                      Why does RM83 13.5(8) forbid to
|>       use address clauses to achieve overlays, then?

13.5(8) must be understood as applying to the overlaying of Ada entities.
What other possible use could there be for an address clause except to
overlay an Ada entity with storage that has some special significance
outside the Ada program (significance either to hardware or software)?
Admittedly, address clauses give rise to a whole bunch of embarassing
questions that are best not asked.  (For example, what happens if you
locate a constant at an address that is changed by some agent outside the
Ada program?)

|>                                                      How do compilers
|>       usually implement this -- does the declare statement force
|>       data allocation on the stack, or is it optimized away, yielding
|>       simply a bypass of the type checking system, just like a `call'
|>       to Unchecked_Conversion should simply translate into _nothing_,
|>       if I'm not all wrong?

No new storage is allocated.  (How could the allocation be on the stack
if it has to be at the address specified in the address clause?) The
specified entity is simply taken to reside at the specified address.

|> In either of these possibilities, what if `Data' is a record with
|> variants (forced to the right representation with a rep clause)? Might
|> Ada get into trouble when interpreting it, or even refuse to work with
|> a record value it has not assigned and checked itself?

Record representation clauses can be used to control the location of
discriminants.  If a compiler cannot support this, it must reject the
record representation clause.  A compiler that accepts the record
representation clause must do the right thing with variants.
(This assumes that the C struct has a member acting in effect as a
discriminant to indicate the currently active variant.  A record
representation clause cannot specify overlapping components unless the
components are in different variants--see RM 13.4(7)-- and an Ada record
type with different variants necessarily has a discriminant.)

--
Norman H. Cohen    ncohen@watson.ibm.com