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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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-7-bit Path: g2news2.google.com!news1.google.com!news.glorb.com!wn13feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail Newsgroups: comp.lang.ada From: anon@anon.org (anon) Subject: Re: Interfacing with C ; an ununsed fields dilemma Reply-To: anon@anon.org (anon) References: X-Newsreader: IBM NewsReader/2 2.0 Message-ID: <5%h3m.98917$d36.38011@bgtnsc04-news.ops.worldnet.att.net> Date: Fri, 03 Jul 2009 06:59:13 GMT NNTP-Posting-Host: 12.64.30.212 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1246604353 12.64.30.212 (Fri, 03 Jul 2009 06:59:13 GMT) NNTP-Posting-Date: Fri, 03 Jul 2009 06:59:13 GMT Organization: AT&T Worldnet Xref: g2news2.google.com comp.lang.ada:6817 Date: 2009-07-03T06:59:13+00:00 List-Id: For the Ada standards, try using "pragma Normalize_Scalars" or you could try using the GNAT's "pragma Initialize_Scalars". The pragma "Initialize_Scalars" is a GNAT implementation pragma. Note: "pragma Initialize_Scalars" seams to allows you to set the value stored in the variables during binding operations. See GNAT user guide (GNAT_UGN) for the binding options to set this value. For complete details for both pragmas, see GNAT RM (GNAT_RM) manual that is installed with the GNAT system. In , =?ISO-8859-1?Q?Hibou57_=28Yannick_Duch=EAne=29?= writes: >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 :)