Re: Should Representation Clauses be complete for each bit?

[Stephen Leake <Stephen.Leake@gsfc.nasa.gov>]

Lowe Anthony A wrote:
> 
> Some of our new Ada folks have written Rep Clauses which do not
> explicitly map every bit in the range of data to a member of the
> record.  (i.e.
>    type x is record
>      one : boolean;
>      two : boolean;
>      three : boolean;
>    end record;
>    for x use record
>      one   at 0 range 0..0;
>      two   at 0 range 3..3;
>      three at 0 range 15..15;
>    end record;
> 
> In the past I have always used a package Rep_Clause_Types which
> defines spare bits types for anywhere from 1 to 31 bits of spare and
> subprograms to set each of the choices to all zeros or ones.  I have
> not found any information in the LRM or Q&S to guide which way is more
> appropriate.
>     On one hand, it is helpful to explicitly state that these bits are
> spare and will not be used for any specific purpose.  If you fill in
> the spare bits with elements, they can be explicitly set to a value
> (ones or zeros).   This is nice for cleanliness, but costs some
> execution time for initialization.  I also am a bit concerned about
> people using the 'spare bit' types instead of creating new types when
> the spare bits mean something.
>     On the other hand, if the compilers do not require you to fill it
> in and the Q&S is quiet on the subject, it must not be that bad to
> do.   It is definitely easier and less crowded to not fill them in.
>     If my description is not too biased I think you can see that I am
> leaning towards requiring each rep clause to be complete.   I am
> interested on other takes on this issue for screaming benifits/costs
> of either approach.

I've had problems leaving bits undefined and then passing them to
Windows API functions. The Windows API has many "flag" arguments that
are easily defined by Ada records. However, the C definition is via
constants with 1 in the appropriate bits. Apparently, the actual API
functions do not always mask out the unused bits.

I've also had problems with comparing test outputs. If you leave bits
undefined, then you get whatever was left in the register from the
previous operation. If you then print this value as hex (for debugging
stream output, say), you may see different values from run to run. I
usually only see different values when changing compilers (GNAT to
ObjectAda), but it could happen when you change optimization levels. The
problem is not that the behavior is undefined, just that the test output
changes, which makes comparing the test results more difficult.

So I've adopted the general policy that all bits must be defined.
-- 
- Stephe