Interfacing with C ; an ununsed fields dilemma

Interfacing with C ; an ununsed fields dilemma

[Hibou57 (Yannick Duchêne)]

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.

But doing so disallow to tell the compiler these fields are to be
initialized to “ zero ” (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 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)

Pleased to read you and have a nice day :)

Re: Interfacing with C ; an ununsed fields dilemma

[Martin]

On Jul 2, 7:20 am, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:
> 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.
>
> But doing so disallow to tell the compiler these fields are to be
> initialized to “ zero ” (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 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)
>
> 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  := 0;
      Filler_1 : Always_0 := 0;
      F1       : Float    := 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 := 0;
      F1 : Float   := 0.0;
   end record;

   function To_Ada (C : C_Rec) return Ada_Rec is
   begin
      return (I1 => C.I1,
              F1 => 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 := To_Ada (C);
end Demo_Filler;

Usual caveats - I haven't run this, it's just a 'pattern' as a demo...

Cheers
-- Martin

reserved fields; was Re: Interfacing with C ; an ununsed fields dilemma

[tmoran]

> 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 ...

  So such a field is not unused - it's currently a version field whose
value is zero, but in the future it may take non-zero values with
meanings other than version number, so "Version_Number" would not
be an appropriate name. "Reserved", or possibly "TBD", would be
appropriate names.

   type C_Rec is record
      I1       : Integer  := 0;
      Reserved : Integer range 0 .. 0 := 0;
      F1       : Float    := 0.0;
   end record;
   for C_Rec use record
      I1       at 0 range  0 .. 31;
      Reserved at 4 range 32 .. 63;
      F1       at 8 range 64 .. 95;
   end record;

Re: Interfacing with C ; an ununsed fields dilemma

[Maciej Sobczak]

On 2 Lip, 08:20, Hibou57 (Yannick Duchêne) <yannick_duch...@yahoo.fr>
wrote:

> 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).
[...]

I think that the most reasonable approach to interfacing with such
APIs is to write a very thin "sanitizing" layer in C that will expose
the interface shaped especially for easy interfacing from Ada.

In other words, think about this complete structure:

Ada application
       |
       | (calls)
       V
Ada interfacing wrapper
       |
       | (interfaces to)
       V
C interface wrapper
       |
       | (provides easy access to)
       V
C messy-crappy-lib

If you think that such a structure would be more work to do (there is
additional C layer to write), then it is not. The comfort that you
gain on the Ada side with clean functions that do not have to mess
with the dodgy details of bit fields, alignment and whatnot, is
certainly worth it.

In some cases it is actually the only way to go, because in some C
libraries the data structure layout can change from version to version
and even though the proper layout is always defined in C header files,
they are not *automatically* understood by Ada. You are not going to
update your Ada wrapper every time, really.

It is also the only way to interface with more elaborated C++
libraries.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Interfacing with C ; an ununsed fields dilemma

[Hibou57 (Yannick Duchêne)]

On 2 juil, 11:45, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> In some cases it is actually the only way to go, because in some C
> libraries the data structure layout can change from version to version
> and even though the proper layout is always defined in C header files,
> they are not *automatically* understood by Ada. You are not going to
> update your Ada wrapper every time, really.

For this single case, this API will not evolve anymore, as it has been
replaced by another, totaly different and incompatible with te two
previous versions... but which no body use.

The idea of a pre-wrapper before Ada is nice and clean (although at
the time, I prefer to not do this way, for some reasons)

> It is also the only way to interface with more elaborated C++
> libraries.
That's true, for C++, this would be mandatory (hope I will never have
to interface C++)


Finally, I think I will simply declare these unused fields in the
public part, in order to be able to give them an initialization value,
but I really do not like it to appears in the public part.

Re: Interfacing with C ; an ununsed fields dilemma

[Georg Bauhaus]

Hibou57 (Yannick Duch�ne) schrieb:

> Finally, I think I will simply declare these unused fields in the
> public part, in order to be able to give them an initialization value,
> but I really do not like it to appears in the public part.

In case you are using current Ada, have you considered
making your type limited an use a "construtor function"?
http://www.adacore.com/2007/05/28/gem-3/

Re: Interfacing with C ; an ununsed fields dilemma

[Hibou57 (Yannick Duchêne)]

On 2 juil, 14:09, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:

> In case you are using current Ada, have you considered
> making your type limited an use a "construtor function"?http://www.adacore.com/2007/05/28/gem-3/

But this still allow an automatic instantion without the required
initialization.

On the other hand, I like this sentence in the document you've
pointed : “ After all, interesting types are usually private, and we
need some way for clients to create and initialize objects. ”

I oftenly feel the same, and I would probably have choose this design
if I were to create a specification from the ground up (perhaps I'm
driven into error by the existing C interface). Reading it in this
context, make me think that perhaps I should use a more abstract
specification, thus make these types (there are numerous records of
the same kind) fully private and define numerous accessors to each of
these types. I will no more bother to declare these unused fields, as
this would be now in the private part.

Re: Interfacing with C ; an ununsed fields dilemma

[Georg Bauhaus]

Hibou57 (Yannick Duch�ne) schrieb:
> On 2 juil, 14:09, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> 
>> In case you are using current Ada, have you considered
>> making your type limited an use a "construtor function"?http://www.adacore.com/2007/05/28/gem-3/
> 
> But this still allow an automatic instantion without the required
> initialization.

No, if you use (<>) in the public view of the type as explained
in Gem #3 then users will have to initalize explicitly;
the only possibility to declare an object of the type, then,
is together with call a public "constructor function" to do
the initalization in place.



> I oftenly feel the same, and I would probably have choose this design
> if I were to create a specification from the ground up (perhaps I'm
> driven into error by the existing C interface). Reading it in this
> context, make me think that perhaps I should use a more abstract
> specification, thus make these types (there are numerous records of
> the same kind) fully private and define numerous accessors to each of
> these types. I will no more bother to declare these unused fields, as
> this would be now in the private part.

Private or not, "uncontrolled" unused bits may have an impact
on future translations (see the reasons Maciej
has listed).  In the private part of a package, then,

(a) users of its public part will not need to consider
the record's representation,

(b) but you can be specific (open, honest, ...) about the
components not used, and whether or not you want them
to be initialized by default etc.

Re: Interfacing with C ; an ununsed fields dilemma

[Maciej Sobczak]

On 2 Lip, 14:01, Hibou57 (Yannick Duchêne) <yannick_duch...@yahoo.fr>
wrote:

> (hope I will never have
> to interface C++)

Why?

You might not *have* to do it, but instead you might actually *want*
to do it.
A number of libraries were exposed to Ada this way with *benefit* to
everybody, so it is not something that should be religiously avoided.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Interfacing with C ; an ununsed fields dilemma

[Hibou57 (Yannick Duchêne)]

On 2 juil, 16:52, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> Why?
>
> You might not *have* to do it, but instead you might actually *want*
> to do it.
> A number of libraries were exposed to Ada this way with *benefit* to
> everybody, so it is not something that should be religiously avoided.
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com
>
> Database Access Library for Ada:www.inspirel.com/soci-ada

Not religiously, just beceause I think this would be more difficult.
May be I'm wrong, but it seems to me that there is not real standard
ABI for C++ (for the comment in passing)

Re: Interfacing with C ; an ununsed fields dilemma

[Maciej Sobczak]

On 3 Lip, 01:21, Hibou57 (Yannick Duchêne) <yannick_duch...@yahoo.fr>
wrote:

> Not religiously, just beceause I think this would be more difficult.

Yes.

> May be I'm wrong, but it seems to me that there is not real standard
> ABI for C++ (for the comment in passing)

That's why writing a sanitizing thin layer in C is a way to go. There
is no need to standardize every corner of all languages, it is enough
to standardize their "common denominators".

Note also that ABI is only part of the problem, so solving it would
not be enough. Other important problems are in name overloading,
templates and exceptions. It is not even clear if standardizing these
at the bit level would be beneficial, because having some
implementation freedom in there ensures a competition opportunity for
compiler writers.
This is exactly the same in Ada, by the way.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Interfacing with C ; an ununsed fields dilemma

[Georg Bauhaus]

Hibou57 (Yannick Duch�ne) schrieb:
> 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),

Omitting things might be acceptable in mathematical
discourse, but actually writing things down helps a
lot in programming, at least it helps me as a reader,
not up for solving (inter-)language puzzles.
You explanation of the record's gap fields is itself a hint
that these components do need some attention.
Shouldn't therefore Martin's example be the way to go?

This has been discussed before, topics included

   for X use all
      record
         ...
      end record;

pragma Zero_Fill and Unchecked_Conversion (for setting bits to 0);

Re: Interfacing with C ; an ununsed fields dilemma

[Martin]

On Jul 2, 10:51 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> Hibou57 (Yannick Duchêne) schrieb:
>
>
>
> > 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),
>
> Omitting things might be acceptable in mathematical
> discourse, but actually writing things down helps a
> lot in programming, at least it helps me as a reader,
> not up for solving (inter-)language puzzles.
> You explanation of the record's gap fields is itself a hint
> that these components do need some attention.
> Shouldn't therefore Martin's example be the way to go?
>
> This has been discussed before, topics included
>
>    for X use all
>       record
>          ...
>       end record;
>
> pragma Zero_Fill and Unchecked_Conversion (for setting bits to 0);

pragma Zero_Fill sounds interesting...but it isn't standard :-(

Cheers
-- Martin

Re: Interfacing with C ; an ununsed fields dilemma

[Hibou57 (Yannick Duchêne)]

On 2 juil, 12:16, Martin <martin.do...@btopenworld.com> wrote:
> pragma Zero_Fill sounds interesting...but it isn't standard :-(
>
> Cheers
> -- Martin
Not standard, and not understood by at least the GNAT compiler

What a pitty, this would have been exactly what I was looking for

A quick search on the web shows that this has been a proposal by
someone in 2004

Re: Interfacing with C ; an ununsed fields dilemma

[Robert A Duff]

"Hibou57 (Yannick Duch�ne)" <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 � 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

Re: Interfacing with C ; an ununsed fields dilemma

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccprcjrsek.fsf@shell01.TheWorld.com...
...
> The compiler cannot ALWAYS do block compare, for two reasons:
> Minus-zero equals plus-zero (for floats).

Also for integers, if you are on a one's complement machine. (Those 
generally are older machines, but some are still in use.)

...
> And user-defined "=" on
> the components gets called in the tagged case.

And soon to be all records (see AI05-0123-1, approved in Brest).

                          Randy.

Re: Interfacing with C ; an ununsed fields dilemma

[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 :)