Re: Zero_Fill pragma, other proposition

[Ludovic Brenta <ludovic.brenta@insalien.org>]

Lionel Draghi writes:
> | De: Jean-Pierre Rosen ...
> | OTOH, I suspect that very few types would need
> | that pragma (as you describe, a couple of types very strongly 
> | connected to hardware), so writing more fields is not really a
> | problem.
> In our case, it's a common problem : we have lots of messages with spare
> fields, and setting them to 0 for out going messages is a requirement.
> (On the other hand, even without this requirement, it would ease regression
> testing.
> Simple regression test tools based on diff raise false alarm because spare
> fields may be whatever on each run).
>
> So, our current policy is to explicitly state each spare. I don't feel
> confortable with this because the low level representation emerge in the
> definition.
> I don't want users to access the spare fields.
> I don't event want users to see the spare fields.
>
> What could be a good deal is to allows spare fields to appear in the
> representation clause.
>
> Kind of :
>
> type Message is record
>    Id   : Message_Id;
>    Data : Byte_Stream;
> end record;
>
> for Message use record
>    Id    at 0 range 0 .. 7;
>    Spare at 0 range 8 .. 15 := 0; --> ADDED
>    Data  at 0 range 16 .. 65;
> end record;
>
> This way, representation stuff don't emerge in the "user's" view,
> but spares are explicit in the "coder's" view.

Even though I like your proposal, I'm not sure that a new language
construct is required.  You can use encapsulation to prevent users
from seeing the spare fields, like this:

package P is
   type Message is record
      Id   : Message_ID;
      Data : Byte_Stream;
   end record;

   -- Primitive operations of Message go here
private
   type Representation is record
      Id    : Message_ID;
      Spare : Eight_Bits;
      Data  : Byte_Stream;
   end record;

   for Representation use record
      Id    at 0 range 0 .. 7;
      Spare at 0 range 8 .. 15;
      Data  at 0 range 16 .. 65;
   end record;
   
   function To_Rep (M : in Message) return Representation;
   function To_Message (R : in Representation) return Message;
end P;


package body P is
   function To_Rep (M : in Message) return Representation is
   begin
      return (Id => M.Id, Spare => 0, Data => R.Data);
   end To_Rep;

   function To_Message (R : in Representation) return Message is
   begin
      return (Id => R.Id, Data => R.Data);
   end To_Message;

   -- Primitive operations of Message convert to Representation whenever
   -- interfacing to hardware
end P;

I realise that your proposal reduces the amount of work required to
achieve this, but the current language does allow you to do what you
want.

-- 
Ludovic Brenta.