Re: Interfacing with C ; an ununsed fields dilemma

[Martin <martin.dowie@btopenworld.com>]

On Jul 2, 7:20 am, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:
> Hello to all,
>
> Once again, a topic about interfacing with C structures.
>
> A lot of C structure are defined with so called “ unused field
> reserved for future use ” (oftenly never used in any future). This
> fields are generally to be initialized to zero, what is required, to
> unsure it will not be errorneously interpreted by the exogenous part
> of the application, specially if it is dynamically linked to the
> application (beceause then, its version or its implementation may be
> differente and unknown of the application which rely on it).
>
> And here is the dilemma :
>
> Using clause representation, it is tempting to simply drop this
> unuseful unusedfields from the visible part of the declaration (yeah
> dear friend, lot cleaner, really tempting), and simply assigning
> nothing to this bit-range in the record representation clause.
>
> But doing so disallow to tell the compiler these fields are to be
> initialized to “ zero ” (at the binary level). And that is less nice.
>
> So a question may comes here : either a way to tell the compiler that
> bit-range left unassigned in the representation clause are all zero-
> bits when an instance of such a record is created by the application,
>
> I've looked at the ARM, and found a sole place about this topic of
> filling gaps :
>
> Annotated RM 2005 says
>
> > 22 * An implementation need not support a component_clause for a component of
> > an extension part if the storage place is not after the storage places of
> > all components of the parent type, whether or not those storage places had
> > been specified.
>
> > 22.a Reason: These restrictions are probably necessary if block equality
> > operations are to be feasible for class-wide types. For block comparison to
> > work, the implementation typically has to fill in any gaps with zero (or
> > one) bits. If a “gap” in the parent type is filled in with a component in a
> > type extension, then this won't work when a class-wide object is passed by
> > reference, as is required.
>
> Ok, for the block comparison to work, implementation tipically fill
> gaps with zero bits.... but what if no block comparison is ever used
> in the application ? Is this behaviour droped ? Further more, this is
> not an implementation requirement, so it is not possible to formally
> rely on it.
>
> Is there another RM entry you know about it ? Is there any running Ada
> Issues about a suggestion to make this behaviour a formalized
> behaviour (a syntax to tell that gaps are to be filled with zero...
> and perhaps 1 as well by the way)
>
> Pleased to read you and have a nice day :)

when I've done this sort of thing I have 2 records - one with
'Filler_1', 'Filler_2', etc, here's a demo:

procedure Demo_Filler is
   type Always_0 is range 0 .. 0;

   type C_Rec is record
      I1       : Integer  := 0;
      Filler_1 : Always_0 := 0;
      F1       : Float    := 0.0;
   end record;
   for C_Rec use record
      I1       at 0 range  0 .. 31;
      Filler_1 at 4 range 32 .. 63;
      F1       at 8 range 64 .. 95;
   end record;

   type C_Rec_Ptr is access all C_Rec;
   pragma Convention (C, C_Rec_Ptr);

   type Ada_Rec is record  -- no fillers
      I1 : Integer := 0;
      F1 : Float   := 0.0;
   end record;

   function To_Ada (C : C_Rec) return Ada_Rec is
   begin
      return (I1 => C.I1,
              F1 => C.F1);
   end To_Ada;

   procedure Get_From_C (C : C_Rec_Ptr);
   pragma Import (C, Get_From_C);

   C : aliased C_Rec;
   A :         Ada_Rec;
begin
   Get_From_C (C'Access);
   A := To_Ada (C);
end Demo_Filler;

Usual caveats - I haven't run this, it's just a 'pattern' as a demo...

Cheers
-- Martin