Record representation : components order

Record representation : components order

[Hibou57 (Yannick Duchêne)]

Good evening to all (evening time here - good morning for the others),

I was looking back at the RM section 13, “ Representation issues ” for
records.

First of all, I noticed somehing I had forgot, with an nice example in
annotion

> 44    For every subtype S:
> 45    S'Size If S is definite, denotes the size [(in bits)] that the implementation would
>         choose for the following objects of subtype S:
> 46    A record component of subtype S when the record type is packed.
> 47    The formal parameter of an instance of Unchecked_Conversion that converts from
>        subtype S to some other subtype.

If a packed record .... or a formal parameter of an unchecked
conversion. To not to be forgotten, otherwise the implementation is
not required to enforce the size attribute given to a subtype, unlinke
when the size attribute is given to an instance of a subtype.

The annotation later:

> 55.j  The fact that the size of an object is not necessarily the same as its subtype can
>         be confusing:
> 55.k  type Device_Register is range 0..2**8 - 1;
>         for Device_Register'Size use 8; -- Confusing!
>         My_Device : Device_Register;
>         for My_Device'Address use To_Address(16#FF00#);

55.l     The programmer might think that My_Device'Size is 8, and that
My_Device'Address
>         points at an 8-bit location. However, this is not true. In Ada 83 (and in Ada 95),
>        My_Device'Size might well be 32, and My_Device'Address might well point at the high-order
>        8 bits of the 32-bit object, which are always all zero bits.

Indeed, confusing

But the question is not there (I point it for concerned people)

Going on in section 13, I did no see about record components order
apart the “ at X range Y .. Z ” which directly specify it.

But looking at some design in some place in the web, people usually do
this way : define some component type with a size clause, and then,
just use these type in some records, most of time, without using any “
at X range Y .. Z ” . But to me, this seems to be unsafe, beceause
components order is not guaranted to be that of the declaration.

Is there something I missed ? I was thinking that an Ada compiler was
allowed to reorder component of a record if it can helps some
efficiency (I know at least a case, where this could help on some old
machine) and thus that the declaration is a the declaration and the
physical repsentation is not required to match what one might suppose,
unless explicitely specified.

But I did not see anything which assert that simply using sized types
and design records with it and a pragma pack without any “ at range ”
can ensure this.

I did not see about the effect of a pragma convention on a
representation. Is it related ?

Re: Record representation : components order

[Hibou57 (Yannick Duchêne)]

Well, I've found an answer, buit this still leave me with a doubt. The
answer first, and the doubt next.

An Ada-Auth discussion with a guy who has forgotten to apply pragma
Convention (C, ...) to the type of the member of a record (not exactly
the subject, while interesting), ends with these words :

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/acs/ac-00023.txt?rev=1.1
says (at the end):
> Now when laying out type Time_Type, it uses textual order for
> the components (this is required by convention C).

“ required by convention C ” : this is what one would expect indeed,
as I did, without beeing sure. But is it stated in the RM ? Annex B.1
does not say such a thing. With the guy (the one who opended the
thread), I agree than some more extensive wording would be required to
fullfill the wish that it is possible to do things in Ada without
relying on a particular compiler's behaviour.

Perhaps it is informally clear to someone, so that is has been left
from the standard (when a thing is obvious to someone, it is easy to
forget to point it).

An other document now, from AdaPower (for a change):
http://www.adapower.com/index.php?Command=Class&ClassID=Advanced&CID=228
says (at the opening):
> pragma Convention(Convention => C) (Christopher Green)
>
> What exactly does "pragma Convention(Convention => C)" do when
> applied to a record type?
>
> It means that record types will be laid out the way C expects them
> to be, whatever that is.
>
> C preserves the order of members within a struct and inserts padding
> so that members will be aligned on the machine-dependent proper
> address boundary for their type.

“ C preserves the order of members within a struct ”, yes that's true,
C do that, but no where a document state what exactly the pragma
Convention for a specific language means independently of a particular
compiler.

Finally, perhaps an annex document would help peoples to feel relieved

This will benefit from beeing more officialy formalized. Putting it in
the core standard wording may be too much, but in an annex, this would
be ok.

What are peoples here think about it ?

N.B. pragma Convention is required when the C specs make use of some
type whose size depends on some configuration. This is not convenient
to use “ at range ” in this case. This is the reason of this thread.

Re: Record representation : components order

[sjw]

On Jul 5, 4:14 am, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:

> N.B. pragma Convention is required when the C specs make use of some
> type whose size depends on some configuration. This is not convenient
> to use “ at range ” in this case. This is the reason of this thread.

No good telling the Ada compiler to use a size (or alignment, or ...)
that the C compiler only knows because of some #defines that are only
visible to the C compilation!

For tcladashell, I have a Tcl script which generates a C program which
generates an Ada spec (the reason for the Tcl script is that there are
at least 3 different kinds of definition required, for several
variables. I suppose I could have used C macros ...). Sample output:

package Tcl_Record_Sizes is

   --  Size macros defined in tcl.h.

   NUM_STATIC_TOKENS : constant := 20;

   TCL_DSTRING_STATIC_SIZE : constant := 200;

   --  Sizes of structs defined in tcl.h.

   Tcl_CallFrame_Size : constant := 44;
   Tcl_CallFrame_Alignment : constant := 4;

Re: Record representation : components order

[Stephen Leake]

"Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr> writes:

> Going on in section 13, I did no see about record components order
> apart the “ at X range Y .. Z ” which directly specify it.
>
> But looking at some design in some place in the web, people usually do
> this way : define some component type with a size clause, and then,
> just use these type in some records, most of time, without using any “
> at X range Y .. Z ” . But to me, this seems to be unsafe, beceause
> components order is not guaranted to be that of the declaration.

You are correct.

If your application requires a specific component order, you must
specify the order in a record representation clause.

Anything else is compiler dependent.

Note that Ada 2005 allows specifying bit field placement using
endian-independent bit numbers.

-- 
-- Stephe

Re: Record representation : components order

[Hibou57 (Yannick Duchêne)]

On 5 juil, 16:10, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> [...]
> If your application requires a specific component order, you must
> specify the order in a record representation clause.
>
> Anything else is compiler dependent.
> [...]
> --
> -- Stephe

And so the two document pointed in the second part of this thread are
wrong ? Finally if its true, the RM does not miss any details and one
must strictly rely on it and nothing else.

Re: Record representation : components order

[Stephen Leake]

"Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr> writes:

> Well, I've found an answer, buit this still leave me with a doubt. The
> answer first, and the doubt next.
>
> An Ada-Auth discussion with a guy who has forgotten to apply pragma
> Convention (C, ...) to the type of the member of a record (not exactly
> the subject, while interesting), ends with these words :
>
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/acs/ac-00023.txt?rev=1.1
> says (at the end):
>> Now when laying out type Time_Type, it uses textual order for
>> the components (this is required by convention C).
>
> “ required by convention C ” : this is what one would expect indeed,
> as I did, without beeing sure. But is it stated in the RM ? Annex B.1
> does not say such a thing. With the guy (the one who opended the
> thread), I agree than some more extensive wording would be required to
> fullfill the wish that it is possible to do things in Ada without
> relying on a particular compiler's behaviour.

That's what record representation clauses are for.

> Perhaps it is informally clear to someone, so that is has been left
> from the standard (when a thing is obvious to someone, it is easy to
> forget to point it).

No, the meaning of "convention C" is deliberately left implementation
defined, so that any given Ada compiler vendor can match any given C
compiler.

> N.B. pragma Convention is required when the C specs make use of some
> type whose size depends on some configuration. This is not convenient
> to use “ at range ” in this case. This is the reason of this thread.

Can you elaborate? I don't understand why you can't use a record
representation clause.

Hmm. Perhaps you have a C compiler that allows you to specify the size
of "int" or some other C type via a command line switch or some other
mechanism. To accomodate that in Ada, you'd need to use different
files, selected by a build switch. It's not the same mechanism, but
it's not very hard, either.

-- 
-- Stephe

Re: Record representation : components order

[Stephen Leake]

sjw <simon.j.wright@mac.com> writes:

> For tcladashell, I have a Tcl script which generates a C program which
> generates an Ada spec 

Recent versions of GNAT have the option -fdump-ada-spec which
generates Ada specs from C and C++ headers. See chapter 25 in the GNAT
User Guide.

-- 
-- Stephe

Re: Record representation : components order

[Jean-Pierre Rosen]

Hibou57 (Yannick Duch�ne) a �crit :
> Well, I've found an answer, buit this still leave me with a doubt. The
> answer first, and the doubt next.
> 
> An Ada-Auth discussion with a guy who has forgotten to apply pragma
> Convention (C, ...) to the type of the member of a record (not exactly
> the subject, while interesting), ends with these words :
> 
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/acs/ac-00023.txt?rev=1.1
> says (at the end):
>> Now when laying out type Time_Type, it uses textual order for
>> the components (this is required by convention C).
> 
> � required by convention C � : this is what one would expect indeed,
> as I did, without beeing sure. But is it stated in the RM ? Annex B.1
> does not say such a thing.
[...]
>> C preserves the order of members within a struct and inserts padding
>> so that members will be aligned on the machine-dependent proper
>> address boundary for their type.
> 
Now, since B.1(2) says:
   A pragma Convention is used to specify that an Ada entity should use
   the conventions of another language"
you clearly have to look at the other language's standard to know the
applicable convention. And there, you'll find that C requires to
preserve order. Note that this is hinted by the end of the paragraph:
   For example, �pragma Convention(Fortran, Matrix);� implies that
   Matrix should be represented according to the conventions of the
   supported Fortran implementation, namely column-major order.

Why doesn't the LRM say it clearly? Remember you never interface with
another language, but with another compiler. And if the target C
compiler does not implement the C standard correctly, the Ada compiler
has to match the C compiler, not the C standard.
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Record representation : components order

[Jacob Sparre Andersen]

Yannick Duch�ne wrote:
> Stephen Leake wrote:

> > If your application requires a specific component order, you must
> > specify the order in a record representation clause.
> >
> > Anything else is compiler dependent.

> And so the two document pointed in the second part of this thread
> are wrong ? Finally if its true, the RM does not miss any details
> and one must strictly rely on it and nothing else.

You should note that the reference manual also refers other documents.
For example does the pragma Convention implicitly refer to the
specifications of other languages/compilers.  And "pragma Convention
(*)" is an implicit record representation clause, which lays out the
type as language/compiler "*" does it.

Things aren't always as simple as they may seem.

Greetings,

Jacob
-- 
"It is a syntax error to write FORTRAN while not wearing a blue tie."

Re: Record representation : components order

[sjw]

On Jul 6, 8:33 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> sjw <simon.j.wri...@mac.com> writes:
> > For tcladashell, I have a Tcl script which generates a C program which
> > generates an Ada spec
>
> Recent versions of GNAT have the option -fdump-ada-spec which
> generates Ada specs from C and C++ headers. See chapter 25 in the GNAT
> User Guide.

Yes, but many people don't have this option yet. Also

* tcl.h isn't really meant to be read by humans, so Ada code generated
from it has similar characteristics, and I'd rather provide something
I know to be at least semi-readable and compilable;

* I'm not sure how settled -fdump-ada-spec is yet;

* in theory tcladashell is compiler-independent.

Re: Record representation : components order

[Stephen Leake]

sjw <simon.j.wright@mac.com> writes:

> On Jul 6, 8:33�am, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>> sjw <simon.j.wri...@mac.com> writes:
>> > For tcladashell, I have a Tcl script which generates a C program which
>> > generates an Ada spec
>>
>> Recent versions of GNAT have the option -fdump-ada-spec which
>> generates Ada specs from C and C++ headers. See chapter 25 in the GNAT
>> User Guide.
>
> Yes, but many people don't have this option yet. Also
>
> * tcl.h isn't really meant to be read by humans, so Ada code generated
> from it has similar characteristics, and I'd rather provide something
> I know to be at least semi-readable and compilable;

Ok.

> * I'm not sure how settled -fdump-ada-spec is yet;

Ok. 

I suppose this could be a standard, defining how various C statements
get translated into Ada, but I suspect that would be far more effort
than it is worth. So we'll just have to trust AdaCore to do a good
job. Since they are motivated by customer needs, I'm not worried :).

> * in theory tcladashell is compiler-independent.

That's not important. You only need to generate the Ada code once
(well, once each time the C code changes); then you can use it with
any compiler. So only the tcladashell maintainer/developer needs
-fdump-ada-spec.

-- 
-- Stephe

Re: Record representation : components order

[sjw]

On Jul 9, 10:28 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> sjw <simon.j.wri...@mac.com> writes:

> > * in theory tcladashell is compiler-independent.
>
> That's not important. You only need to generate the Ada code once
> (well, once each time the C code changes); then you can use it with
> any compiler. So only the tcladashell maintainer/developer needs
> -fdump-ada-spec.

This is perhaps an unusual example, and I'm not sure it would actually
happen, but:

struct {
  int i;
#ifdef SOME_BIZARRE_COMPILER_I_DONT_HAVE_BUT_YOU_DO
  int j;
#endif
} foo;

Also, I tried 'gcc -fdump-spec /usr/include/tcl.h' and got the
following out:

i386_utypes_h.ads
stdarg_h.ads
stdio_h.ads
sys_utypes_h.ads
tcl_h.ads
tcldecls_h.ads
tclplatdecls_h.ads
utypes_h.ads

and stdio_h.ads contains eg
   subtype size_t is i386_utypes_h.uu_darwin_size_t;

so I could hardly hope that would work with Aonix on Windows!

Re: Record representation : components order

[Stephen Leake]

sjw <simon.j.wright@mac.com> writes:

> On Jul 9, 10:28�am, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>> sjw <simon.j.wri...@mac.com> writes:
>
>> > * in theory tcladashell is compiler-independent.
>>
>> That's not important. You only need to generate the Ada code once
>> (well, once each time the C code changes); then you can use it with
>> any compiler. So only the tcladashell maintainer/developer needs
>> -fdump-ada-spec.
>
> This is perhaps an unusual example, and I'm not sure it would actually
> happen, but:
>
> struct {
>   int i;
> #ifdef SOME_BIZARRE_COMPILER_I_DONT_HAVE_BUT_YOU_DO
>   int j;
> #endif
> } foo;

More likely the #ifdef is on the OS; for example, the "fstat" struct
has different components on different operating systems. In either
dase, the solution is the same as below.

>
> Also, I tried 'gcc -fdump-spec /usr/include/tcl.h' and got the
> following out:
>
> i386_utypes_h.ads
> stdarg_h.ads
> stdio_h.ads
> sys_utypes_h.ads
> tcl_h.ads
> tcldecls_h.ads
> tclplatdecls_h.ads
> utypes_h.ads
>
> and stdio_h.ads contains eg
>    subtype size_t is i386_utypes_h.uu_darwin_size_t;
>
> so I could hardly hope that would work with Aonix on Windows!

Ok, so you need to keep track of separate Ada files for each target,
where a target is a combination of Ccompiler and OS.

You still only run -fdump-ada-spec when the C code changes.
-- 
-- Stephe