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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,5afd69f1373c41cc,start X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,CP1252 Path: g2news2.google.com!postnews.google.com!d32g2000yqh.googlegroups.com!not-for-mail From: =?ISO-8859-1?Q?Hibou57_=28Yannick_Duch=EAne=29?= Newsgroups: comp.lang.ada Subject: Interfacing with C ; an ununsed fields dilemma Date: Wed, 1 Jul 2009 23:20:37 -0700 (PDT) Organization: http://groups.google.com Message-ID: NNTP-Posting-Host: 86.75.149.248 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1246515640 9894 127.0.0.1 (2 Jul 2009 06:20:40 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 2 Jul 2009 06:20:40 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: d32g2000yqh.googlegroups.com; posting-host=86.75.149.248; posting-account=vrfdLAoAAAAauX_3XwyXEwXCWN3A1l8D User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; fr),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:6788 Date: 2009-07-01T23:20:37-07:00 List-Id: 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 componen= t 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 ha= d > 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 =93gap=94 in the parent type is filled in with a componen= t in a > type extension, then this won't work when a class-wide object is passed b= y > 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 :)