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,ASCII Path: g2news2.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Interfacing with C ; an ununsed fields dilemma Date: Thu, 02 Jul 2009 11:55:31 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: pcls6.std.com 1246550131 10124 192.74.137.71 (2 Jul 2009 15:55:31 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 2 Jul 2009 15:55:31 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:sOjTP/7Ftpb+/VIuKhCCuXREYP4= Xref: g2news2.google.com comp.lang.ada:6805 Date: 2009-07-02T11:55:31-04:00 List-Id: "Hibou57 (Yannick Duch�ne)" writes: > 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. No, don't do that. It causes endless trouble. I suggest you make the type private, and provide accessor functions at an appropriate level of abstraction. Make the full type a record type, and make sure every field is explicit. Do not leave implicit gaps: record ... Must_Be_Zero : Three_Bits := 0; Make sure all your constructor functions set the gaps to zero, or whatever is required. Oh, and use unknown discriminants: type T(<>) is private; -- or limited private That way, clients cannot create objects without calling the appropriate constructor functions. And these functions always zero-out things correctly, so clients can't create bad data. > 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) No, there is no requirement for the compiler to zero gaps, and there never will be. The above AARM annotation is talking about an implementation option: The compiler can choose to zero the gaps, and then it can rely on the fact that the gaps are zero and implement "=" as a block compare. Or it can choose not to zero the gaps, and implement "=" component-by-component. Or some combination of these. So if you want your gaps zeroed, you must declare them as explicit components, and zero them yourself. Some compilers can put components of a type extension in between components of the parent type, either by default, or when you ask for that with a rep clause. GNAT has implemented something like that (very recently -- you probably don't have this version yet). The compiler cannot ALWAYS do block compare, for two reasons: Minus-zero equals plus-zero (for floats). And user-defined "=" on the components gets called in the tagged case. - Bob