From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,5afd69f1373c41cc X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,CP1252 Path: g2news2.google.com!postnews.google.com!l12g2000yqo.googlegroups.com!not-for-mail From: Martin Newsgroups: comp.lang.ada Subject: Re: Interfacing with C ; an ununsed fields dilemma Date: Thu, 2 Jul 2009 02:25:00 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 20.133.0.8 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1246526700 13642 127.0.0.1 (2 Jul 2009 09:25:00 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 2 Jul 2009 09:25:00 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: l12g2000yqo.googlegroups.com; posting-host=20.133.0.8; posting-account=g4n69woAAACHKbpceNrvOhHWViIbdQ9G User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11,gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:6790 Date: 2009-07-02T02:25:00-07:00 List-Id: On Jul 2, 7:20=A0am, Hibou57 (Yannick Duch=EAne) wrote: > Hello to all, > > Once again, a topic about interfacing with C structures. > > A lot of C structure are defined with so called =93 unused field > reserved for future use =94 (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 =93 zero =94 (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 compon= ent 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 equalit= y > > operations are to be feasible for class-wide types. For block compariso= n to > > work, the implementation typically has to fill in any gaps with zero (o= r > > one) bits. If a =93gap=94 in the parent type is filled in with a compon= ent 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 :=3D 0; Filler_1 : Always_0 :=3D 0; F1 : Float :=3D 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 :=3D 0; F1 : Float :=3D 0.0; end record; function To_Ada (C : C_Rec) return Ada_Rec is begin return (I1 =3D> C.I1, F1 =3D> 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 :=3D To_Ada (C); end Demo_Filler; Usual caveats - I haven't run this, it's just a 'pattern' as a demo... Cheers -- Martin