Re: Interfacing with C ; an ununsed fields dilemma

[anon@anon.org (anon)]

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 <faaa30f7-d69b-4c73-ae70-9b01d3804077@d32g2000yqh.googlegroups.com>, =?ISO-8859-1?Q?Hibou57_=28Yannick_Duch=EAne=29?= <yannick_duchene@yahoo.fr> 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 :)