Default rep specs for record types - documented??

Default rep specs for record types - documented??

[Anonymous Coward]

I'm interested in finding out what the default representation of a
record type is.  Can I expect the sequence of elements in the default
representation to match the sequence they are defined in?

Pointers to where this information can be found would also be
appreciated, as Cohen's book and Google fail to answer this.

Re: Default rep specs for record types - documented??

[Steve]

"Anonymous Coward" <bogus_addy@bogus_domain.net> wrote in message 
news:slrndmloee.kq0.bogus_addy@tango.mindfuq.org...
> I'm interested in finding out what the default representation of a
> record type is.  Can I expect the sequence of elements in the default
> representation to match the sequence they are defined in?
>
> Pointers to where this information can be found would also be
> appreciated, as Cohen's book and Google fail to answer this.
>

Look in the Ada 95 LRM section 13, Representation Issues

Section 13.1 paragraph 19

If an aspect of representation of an entity is not specified, it is chosen 
by default in an unspecified manner.

So... if it matters, use a representation clause.

Steve
(The Duck)

Re: Default rep specs for record types - documented??

[Anonymous Coward]

In article <meKdnXXIJd6tVPfeRVn-vw@comcast.com>, Steve wrote:
> 
> Look in the Ada 95 LRM section 13, Representation Issues
> 
> Section 13.1 paragraph 19
> 
> If an aspect of representation of an entity is not specified, it is
> chosen by default in an unspecified manner.
> 
> So... if it matters, use a representation clause.

Thanks for the feedback.  Essentially what that is saying is that
there are no guarantees for what to expect from a default
representation.  It bothers me to read this, because it counters my
understanding - and counters what Cohen has written in ADA as a Second
Language.

  Example: Cohen states that enumerated types are guaranteed to have a
  representation that numbers the first element as zero, and increases
  sequentially.  Is this not really guaranteed?

What's disappointing is that rep specs add considerable clutter.
Readable code avoids redundancy, so having default representation
aspects that are guaranteed enable less noisey code.  I'm not looking
forward to rep specing records bit for bit simply to enforce the same
order of elements that's specified in the operation specs.

Re: Default rep specs for record types - documented??

[Jeffrey R. Carter]

Anonymous Coward wrote:

>   Example: Cohen states that enumerated types are guaranteed to have a
>   representation that numbers the first element as zero, and increases
>   sequentially.  Is this not really guaranteed?

It is guaranteed. ARM 13.4 says, "For nonboolean enumeration types, if the 
coding is not specified for the type, then for each value of the type, the 
internal code shall be equal to its position number."

ARM 3.5.1 says, "The position number of the value of the first listed 
enumeration literal is zero; the position number of the value of each subsequent 
enumeration literal is one more than that of its predecessor in the list."

So, this representation is specified by the language. Therefore, 13.1 doesn't 
apply to enumeration types. For record types, ARM 13.5.1 says, "If no 
component_clause is given for a component, then the choice of the storage place 
for the component is left to the implementation. If component_clauses are given 
for all components, the record_representation_clause completely specifies the 
representation of the type and will be obeyed exactly by the implementation." 
Therefore, 13.1 does apply to record types.

> What's disappointing is that rep specs add considerable clutter.
> Readable code avoids redundancy, so having default representation
> aspects that are guaranteed enable less noisey code.  I'm not looking
> forward to rep specing records bit for bit simply to enforce the same
> order of elements that's specified in the operation specs.

If you need a specific representation for a record, you must specify it. I would 
do this even if I knew the compiler would choose the same layout by default; 
anything less is simply asking for a subtle error later. You usually only need a 
specific representation for types used for interfacing.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: Default rep specs for record types - documented??

[Steve]

"Jeffrey R. Carter" <spam@spam.com> wrote in message 
news:TlCaf.1406$uD5.768@newsread3.news.pas.earthlink.net...
> Anonymous Coward wrote:
>
>>   Example: Cohen states that enumerated types are guaranteed to have a
>>   representation that numbers the first element as zero, and increases
>>   sequentially.  Is this not really guaranteed?
>
> It is guaranteed. ARM 13.4 says, "For nonboolean enumeration types, if the 
> coding is not specified for the type, then for each value of the type, the 
> internal code shall be equal to its position number."
>
> ARM 3.5.1 says, "The position number of the value of the first listed 
> enumeration literal is zero; the position number of the value of each 
> subsequent enumeration literal is one more than that of its predecessor in 
> the list."
>
> So, this representation is specified by the language. Therefore, 13.1 
> doesn't apply to enumeration types... [snip]

I disagree with this conclusion.  While I agree that 3.5.1 describes the 
relation between the representation values, it does not define the 
representation.

The number of bits used to represent enumerated values can certainly vary 
between compilers, and can in fact be given a specific size through a 
representation clause (for myenum'size use numBits).

So... if your writing code where representation matters, you need to use 
some form of representation clause for enumeration types as well.

Also:
You can use a representation clause for specific values in an enum.  The 
'succ and 'pred attributes will always give sequential access based on how 
values are declared in the enumeration, but if you use Unchecked_Conversion 
to get at the underlying value, it will match the representation clause.

Steve
(The Duck)

[snip]
>
> -- 
> Jeff Carter
> "Now go away or I shall taunt you a second time."
> Monty Python & the Holy Grail
> 07 

Re: Default rep specs for record types - documented??

[Jeffrey R. Carter]

Steve wrote:
> 
> I disagree with this conclusion.  While I agree that 3.5.1 describes the 
> relation between the representation values, it does not define the 
> representation.

ARM 3.5.1 defines the position numbers, and ARM 13.4 specifies that the 
representation will be the same as the position numbers unless specified otherwise.

-- 
Jeff Carter
"Have you gone berserk? Can't you see that that man is a ni?"
Blazing Saddles
38

Re: Default rep specs for record types - documented??

[Steve]

"Jeffrey R. Carter" <spam@spam.com> wrote in message 
news:YNWaf.50$Xo.35@newsread2.news.pas.earthlink.net...
> Steve wrote:
>>
>> I disagree with this conclusion.  While I agree that 3.5.1 describes the 
>> relation between the representation values, it does not define the 
>> representation.
>
> ARM 3.5.1 defines the position numbers, and ARM 13.4 specifies that the 
> representation will be the same as the position numbers unless specified 
> otherwise.
>

Yes, what is the representation of a "position number"?

Is a position number 8 bits?  16 bits? 32 bits?

Isn't it true that for the definition:

  type Color is ( Red, Green, Blue );

Compiler A may choose to use 8 bits to represent an instance of Color, while 
compiler B may use 32 bits to represent an instance of color?

But if you add a representation clause:

  for Color'size use 8;

All compilers will use the same number of bits to represent an instance of 
color?

You're missing my point.

Steve
(The Duck)

> -- 
> Jeff Carter
> "Have you gone berserk? Can't you see that that man is a ni?"
> Blazing Saddles
> 38 

Re: Default rep specs for record types - documented??

[Anonymous Coward]

In article <Qs6dndQOsuQXkPPeRVn-qw@comcast.com>, Steve wrote:
> "Jeffrey R. Carter" <spam@spam.com> wrote in message 
> news:YNWaf.50$Xo.35@newsread2.news.pas.earthlink.net...
>> Steve wrote:
>>>
>>> I disagree with this conclusion.  While I agree that 3.5.1 describes the 
>>> relation between the representation values, it does not define the 
>>> representation.
>>
>> ARM 3.5.1 defines the position numbers, and ARM 13.4 specifies that the 
>> representation will be the same as the position numbers unless specified 
>> otherwise.
>>
> 
> Yes, what is the representation of a "position number"?
> 
> Is a position number 8 bits?  16 bits? 32 bits?

You guys are arguing semantics at this point.  There are multiple
*aspects* of a representation specification.  In the case of
enumerations, there are four aspects that define the representation:

  mapping of codes to tags
  object size
  value size
  alignment

Jeff was talking about the mapping, and you're talking about the size.
The mapping has a default rep spec guaranteed by the ARM, while the
object size does not have a default rep spec.

> Isn't it true that for the definition:
> 
>   type Color is ( Red, Green, Blue );
> 
> Compiler A may choose to use 8 bits to represent an instance of Color, while 
> compiler B may use 32 bits to represent an instance of color?
> 
> But if you add a representation clause:
> 
>   for Color'size use 8;
> 
> All compilers will use the same number of bits to represent an instance of 
> color?

That is true.  However, it would be silly to provide a complete rep
spec, and write:

  for Color use (Red => 0, Green => 1, Blue => 2); --redundant
  for Color'size use 8;                            --interesting
  for Color'alignment use 1;                       --not sure on this

because the mapping rep clause would be redundant noise.  It's
fortunate that the ARM provides default rep specs for some aspects of
representation so we can be concise without giving up precision.

Re: Default rep specs for record types - documented??

[Jeffrey R. Carter]

Steve wrote:
> 
> You're missing my point.

So it seems. And you're missing mine.

-- 
Jeff Carter
"C's solution to this [variable-sized arrays] has real problems,
and people who are complaining about safety definitely have a point."
Dennis Ritchie
25

Re: Default rep specs for record types - documented??

[Steve]

"Jeffrey R. Carter" <spam@spam.com> wrote in message 
news:SjDbf.744$Id6.15@newsread1.news.pas.earthlink.net...
> Steve wrote:
>>
>> You're missing my point.
>
> So it seems. And you're missing mine.
>

Not at all.

I was trying to make a different point.

Steve
(The Duck)

> -- 
> Jeff Carter
> "C's solution to this [variable-sized arrays] has real problems,
> and people who are complaining about safety definitely have a point."
> Dennis Ritchie
> 25 

Re: Default rep specs for record types - documented??

[Robert A Duff]

"Steve" <nospam_steved94@comcast.net> writes:

> But if you add a representation clause:
> 
>   for Color'size use 8;
> 
> All compilers will use the same number of bits to represent an instance of 
> color?

No (unfortunately).  It means "use at least 8 bits for objects".
A compiler is free to allocate 32.  To control the size of objects,
you have to use 'Size on the object, or, if it's a component,
a record rep clause or a 'Component_Size on an array.

- Bob

Re: Default rep specs for record types - documented??

[Anonymous Coward]

In article <wcc64qw821y.fsf@shell01.TheWorld.com>, Robert A Duff wrote:
> "Steve" <nospam_steved94@comcast.net> writes:
> 
>> But if you add a representation clause:
>> 
>>   for Color'size use 8;
>> 
>> All compilers will use the same number of bits to represent an instance of 
>> color?
> 
> No (unfortunately).  It means "use at least 8 bits for objects".
> A compiler is free to allocate 32.  To control the size of objects,
> you have to use 'Size on the object, or, if it's a component,
> a record rep clause or a 'Component_Size on an array.

I keep getting to a point where I think I've mastered these rep specs,
and yet more gotchas emerge.  I had no idea I could control the
representation of objects independant of the representation of their
types.

I'm shocked to hear that size specs on types are merely a *minimum*.
Can I at least rely on pragma convention to guarantee an absolute size
on enums/integers?

As for records, I've imposed sizes on all my rep spec'd record types.
It would normally be needless, but to protect the maintainer from
accidentally defining a partial rep spec as the operational spec
grows, I've added a size spec so an error will be thrown at compile
time.  

It seems your statement about size specs on types only being a minimum
does not apply to record types, correct?  Here is some code that fails
to compile because the operational spec forces growth beyond that of
the size spec:

   procedure Record_Experiment is

      type Cuban_Aid_In_USD is range 0..50_000;

      type Bushs_Record is record
         Iraq_WoMD_Count         : Natural;
         Dead_Americans          : Positive;
         Dead_Civilians          : Positive;
         Deficit_In_Thousands    : Integer;
         Aid_Offered_To_Cuba     : Cuban_Aid_In_USD;
      end record;

      for Bushs_Record use record
         Iraq_WoMD_Count      at  0 range 0..31;
         Dead_Americans       at  4 range 0..31;
         Dead_Civilians       at  8 range 0..31;
         Deficit_In_Thousands at 12 range 0..31;
      end record;

      --The following line breaks the compile,
      --which is expected and desirable.
      --
      for Bushs_Record'Size use 128;

      President : Bushs_Record;

      --The following line just illustrates that
      --the object size spec can differ from the
      --type size spec.
      --
      for President'Size use 160;

   begin
      null;
   end Record_Experiment;

In this case, I added "Aid_Offered_To_Cuba" to the operational spec,
forcing the record to exceed 128 bytes, which causes an error.  This
seems like the best protection, but it's still inadequite because a
neglectful maintainer can still increase the size spec without
completing the layout.

Re: Default rep specs for record types - documented??

[Jeffrey R. Carter]

Anonymous Coward wrote:

> It seems your statement about size specs on types only being a minimum
> does not apply to record types, correct?  

Incorrect. A 'Size specifies the minimum size the compiler may use for objects 
of the type. The compiler may use larger sizes for objects if not otherwise 
constrained. The size specified by 'Size will be used in certain instances, such 
as when the type is used for a component of a packed composite type. Thus, all 
values of the type must fit in the specified size.

Thus

type T is mod 64;
for T'Size use 2;

fails because you cannot represent that range of values in 2 bits.

-- 
Jeff Carter
"C++ is like giving an AK-47 to a monk, shooting him
full of crack and letting him loose in a mall and
expecting him to balance your checking account
'when he has the time.'"
Drew Olbrich
52

Re: Default rep specs for record types - documented??

[Robert A Duff]

Anonymous Coward <spam@spam.com> writes:

> I'm shocked to hear that size specs on types are merely a *minimum*.

Well, most compilers do something a little more sensible than what the
RM minimally requires.

But surely it makes no sense for the size of an object to always be the
same as the type's size.  Boolean'Size = 1, but you want to allocate
Boolean variables in 32-bit registers, quite often.

During the Ada 9X project, I used to say that 'Size is like one of those
shower controls where you control the temperature and the amount of
water with one knob.  You can get a trickle of cold water, or a torrrent
of hot water, but you can't get a trickle of hot water.  You really want
two knobs.

That's pretty-much what GNAT did with 'Value_Size versus 'Object_Size.

> Can I at least rely on pragma convention to guarantee an absolute size
> on enums/integers?

I believe that's the intent.

> As for records, I've imposed sizes on all my rep spec'd record types.
> It would normally be needless, but to protect the maintainer from
> accidentally defining a partial rep spec as the operational spec
> grows, I've added a size spec so an error will be thrown at compile
> time.  
> 
> It seems your statement about size specs on types only being a minimum
> does not apply to record types, correct?

Jeff answered this.  By "minumim", I meant that _if_ the compiler
accepts the rep clause, it must allocate at least that many bits for
objects.  But "for T'Size use 0;" is still illegal for most types.

- Bob

ADA compilers can reject types arbitrarily?

[Anonymous Coward]

In article <wcchdafhxo5.fsf@shell01.TheWorld.com>, 
Robert A Duff wrote:
> 
> But surely it makes no sense for the size of an object to always be
> the same as the type's size.  Boolean'Size = 1, but you want to
> allocate Boolean variables in 32-bit registers, quite often.

Ah, yes.. I had forgotten that a types size is the same as the value
size, since I was dealing with records.  It didn't occur to me that
record type size specs should really be treated the same as they would
be w/ integers; so that makes sense.  Considering type sizes are
really value sizes, it's more clear to me now why T'size would only
specify a minimum.  I assume I can expect an O'size spec to be
absolute (O being an object).

I'm going to backpeddle on how I write interfacing records now.  I've
rep spec'd the layout of record types (even when the default layout
matches) in order to freeze the layout, in case later on the ADA
compiler changes.  Then I wrote size specs for those records to cause
a compile time error if the operational spec grows independant of the
rep spec.  

But since I technically cannot count on the size spec of a record type
to be an upper limit, I must apply a size spec to at least one object
of the rep spec'd type.  That's pretty ugly, considering objects
aren't always instantiated in the package of the type definition.  So
then I might be tempted to create dummy objects for the purpose of
protecting against partial rep specs.

It's really tempting to scrap the whole idea of writing correct ADA
code, in favor of compiler dependant but readable code.

> Jeff answered this.  By "minumim", I meant that _if_ the compiler
> accepts the rep clause, it must allocate at least that many bits for
> objects.  But "for T'Size use 0;" is still illegal for most types.

No way!  So an ADA compiler can arbitrarily decide whether to accept a
rep spec?  From the ARM, you seem to be correct:

  13.1 (13): A representation or operational item that is not
     	     supported by the implementation is illegal, or raises an
     	     exception at run time.

Amazing.  So an ADA compiler can even reject an operational spec, and
still be considered an ADA compiler.  ie. an ADA compiler can reject:

  type my_record is record
    my_integer : integer;
  end record;

I think that is gives way too much freedom to the compiler.
Technically any ADA compiler can reject my composit types, and I have
no expectation that my code will run.  I'm blown away by this.  Even
worse, the compiler doesn't have to reject the types at compile time
-- it can wait until run time to raise exceptions.  What am I missing?

Re: ADA compilers can reject types arbitrarily?

[tmoran]

> What am I missing?
  A reasonable approach to the problem.  Too much paranoia is unproductive.

Re: ADA compilers can reject types arbitrarily?

[Robert A Duff]

Anonymous Coward <nospam@nospam.com> writes:

> In article <wcchdafhxo5.fsf@shell01.TheWorld.com>, 
> Robert A Duff wrote:
> > 
> > But surely it makes no sense for the size of an object to always be
> > the same as the type's size.  Boolean'Size = 1, but you want to
> > allocate Boolean variables in 32-bit registers, quite often.
> 
> Ah, yes.. I had forgotten that a types size is the same as the value
> size, since I was dealing with records.  It didn't occur to me that
> record type size specs should really be treated the same as they would
> be w/ integers; so that makes sense.

Well, records can be small, too.  E.g a packed record containing 
three booleans could have 'Size = 3, but you want to allocate objects in
a 32-bit register.

>...Considering type sizes are
> really value sizes, it's more clear to me now why T'size would only
> specify a minimum.  I assume I can expect an O'size spec to be
> absolute (O being an object).

Yes.

> No way!  So an ADA compiler can arbitrarily decide whether to accept a
> rep spec?

No, there are all kinds of rules and regulations about what a compiler
has to support, and what it is allowed to support.  See section C.2,
which applies if the SP annex is supported.  I think you can safely
count on SP annex support in all Ada compilers of interest.

My example was T'Size = 0 -- there aren't many types that fit in 0 bits.

- Bob

Re: ADA compilers can reject types arbitrarily?

[Simon Wright]

Anonymous Coward <nospam@nospam.com> writes:

> Amazing.  So an ADA compiler can even reject an operational spec, and
> still be considered an ADA compiler.  ie. an ADA compiler can reject:
>
>   type my_record is record
>     my_integer : integer;
>   end record;

I don't think a compiler that rejected _that_ would have many users.

> Technically any ADA compiler can reject my composit types, and I
> have no expectation that my code will run.

Well, it's more that your code (which is not supported by the
implementation) won't get a chance to run because it won't
compile. Better than failing at run time because of misaligned data.

By the way, it's properly Ada not ADA ...

Adaists Deny Acronym. (was: ADA compilers can reject types arbitrarily?)

[Björn Persson]

Simon Wright wrote:
> By the way, it's properly Ada not ADA ...

I've been wondering when someone was going to say that. :-) I'm 
surprised that it took so long this time.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Adaists Deny Acronym.

[Simon Wright]

Bj�rn Persson <spam-away@nowhere.nil> writes:

> Simon Wright wrote:
>> By the way, it's properly Ada not ADA ...
>
> I've been wondering when someone was going to say that. :-) I'm
> surprised that it took so long this time.

Me too. I was trying to be very quiet about it, though I admit silence
would have been quieter.

Re: Adaists Deny Acronym. (was: ADA compilers can reject types arbitrarily?)

[Samuel Tardieu]

>>>>> "Bj�rn" == Bj�rn Persson <spam-away@nowhere.nil> writes:

Bj�rn> Simon Wright wrote:
>> By the way, it's properly Ada not ADA ...

Bj�rn> I've been wondering when someone was going to say that. :-) I'm
Bj�rn> surprised that it took so long this time.

As long as it gets buried in an otherwise useful answer, I find this
appropriate. What I don't like is when people make a post with only
that "information".

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: ADA compilers can reject types arbitrarily?

[Jeff Creem]

Anonymous Coward wrote:
> In article <wcchdafhxo5.fsf@shell01.TheWorld.com>, 

> 
> Amazing.  So an ADA compiler can even reject an operational spec, and
> still be considered an ADA compiler.  ie. an ADA compiler can reject:
> 
>   type my_record is record
>     my_integer : integer;
>   end record;
> 
> I think that is gives way too much freedom to the compiler.
> Technically any ADA compiler can reject my composit types, and I have
> no expectation that my code will run.  I'm blown away by this.  Even
> worse, the compiler doesn't have to reject the types at compile time
> -- it can wait until run time to raise exceptions.  What am I missing?

You know...Sometimes we take the whole idea of the letter of the spec 
too far. I don't think there is anything that prevents a compiler from 
implementing multiplication with a loop doing repetative addition but I 
have also never seen a compiler that does it.

While I have seen a vendor or two hang their lackluster performance on 
some corner case wording of the reference manual, at some point 
(especially in this post Ada mandate world) you have to expect market 
pressures will prevent compilers from doing things that are totally idiodic.

There are places where perhaps the LRM could be made a little bit tigher 
but in general the freedom is there to allow support on strange 
computing architectures. It is a shame that we pay for this with 
ambiguity on all of the "real" computing architectures.....

Re: Default rep specs for record types - documented??

[Simon Wright]

Anonymous Coward <spam@spam.com> writes:

> As for records, I've imposed sizes on all my rep spec'd record
> types.  It would normally be needless, but to protect the maintainer
> from accidentally defining a partial rep spec as the operational
> spec grows, I've added a size spec so an error will be thrown at
> compile time.

Don't forget to consider alignment issues,especially as affected by
processor type; for instance, a GNAT Ada.Calendar.Time is 8 bytes
long, and has alignment of 4 bytes (the maximum) on x86 but alignment
of 8 bytes on PowerPC.

   with Ada.Calendar;
   package Align is
      type R is record
         B : Boolean;
         T : Ada.Calendar.Time;
      end record;
   end Align;

=>

   Representation information for unit Align (spec)
   ------------------------------------------------

   for R'Size use 128;
   for R'Alignment use 8;
   for R use record
      B at 0 range  0 ..  7;
      T at 8 range  0 .. 63;
   end record;

Re: Default rep specs for record types - documented??

[Stephen Leake]

Anonymous Coward <bogus_addy@bogus_domain.net> writes:

> In article <meKdnXXIJd6tVPfeRVn-vw@comcast.com>, Steve wrote:
>
> What's disappointing is that rep specs add considerable clutter.

Yes. Ada explicitly favors being precise over being concise.

> Readable code avoids redundancy, so having default representation
> aspects that are guaranteed enable less noisey code. 

Representation clauses are not 'redundant'; they provide information
that is not provided by the type declaration.

The compiler ensures that the names are spelled the same, and the
locations do not overlap.

One problem is that the compiler does _not_ warn you if you leave a
component out of the rep clause; a 'pragma Complete_Representation'
would be nice. Specifying the total size can mitigate this, but I
recently had a bug due to this problem.

> I'm not looking forward to rep specing records bit for bit simply to
> enforce the same order of elements that's specified in the operation
> specs.

If 'operation specs' are defining the hardware you are interfacing to,
then yes, you need a rep clause for each hardware register. The time
spent writing those clauses _will_ be repaid later when it comes to
testing on the hardware; there _will_ be fewer bugs.

Someone mentioned a 'pragma Preserve_Layout', which presumably means
"assume a representation clause that puts things in declaration order,
with the base size for each component, and no gaps". That would be
useful, in situations where the type declarations do in fact match the
hardware precisely. Hmm. That is true for most of the rep clauses I've
written recently. I'll have to suggest that to AdaCore as a possible
enhancement; it would have prevented my bug. 

-- 
-- Stephe

Re: Default rep specs for record types - documented??

[Marc A. Criley]

Stephen Leake wrote:

> One problem is that the compiler does _not_ warn you if you leave a
> component out of the rep clause; a 'pragma Complete_Representation'
> would be nice. Specifying the total size can mitigate this, but I
> recently had a bug due to this problem.

A couple years ago the idea of adding such a pragma, albeit with some 
other name, was submitted to the ARG, and there was some discussion on 
it.  It was ultimately rejected due to being, as I vaguely recall, of 
being of insufficient value to justify the effort.

(Though I think Randy B offered to implement it in Janus Ada if someone 
would buy a copy of Janus and request that it be added.  But that was then.)

-- Marc A. Criley
-- McKae Technologies
-- DTraq - XPath In Ada - XML EZ Out

Re: Default rep specs for record types - documented??

[Georg Bauhaus]

Marc A. Criley wrote:
> Stephen Leake wrote:
> 
>> One problem is that the compiler does _not_ warn you if you leave a
>> component out of the rep clause; a 'pragma Complete_Representation'
>> would be nice. Specifying the total size can mitigate this, but I
>> recently had a bug due to this problem.
> 
> 
> A couple years ago the idea of adding such a pragma, albeit with some 
> other name, was submitted to the ARG, and there was some discussion on 
> it.  It was ultimately rejected due to being, as I vaguely recall, of 
> being of insufficient value to justify the effort.

I remember someone suggesting

   for R use all
      record
         ...
      end record;

Wouldn't that work nicely, and be fairly easy to parse, both
for the reader, and for the parser?


-- Georg 

Re: Default rep specs for record types - documented??

[Britt Snodgrass]

I've sometimes thought it would be good to just make the record
representation an optional part of the declaration, e.g.

    type Record_Type is
        record
            Field_0 : Integer_16 at 0 range  0 .. 15;
            Field_1 : Integer_32 at 0 range 16 .. 47;
            Field_2 : Integer_64 at 0 range 48 .. 111;
        end record;

I'm sure there are drawbacks but it seems less error prone and less
verbose.

-- Britt

Re: Default rep specs for record types - documented??

[Stephen Leake]

Stephen Leake <stephen_leake@acm.org> writes:

> Someone mentioned a 'pragma Preserve_Layout', which presumably means
> "assume a representation clause that puts things in declaration order,
> with the base size for each component, and no gaps". That would be
> useful, in situations where the type declarations do in fact match the
> hardware precisely. Hmm. That is true for most of the rep clauses I've
> written recently. I'll have to suggest that to AdaCore as a possible
> enhancement; it would have prevented my bug. 

I've submitted the following to AdaCore:

I had a record:

record_byte_length : constant := 4;

type Record_Type is record
    field_1 : Integer_16;
    field_2 : Integer_16;
end record;

for record_type use record
    Field_1 at 0 range 0 .. 15;
    field_2 at 2 range 0 .. 15;
end record;
for record_type'size use record_byte_length * 8;

Then I needed to add a field, which should go before the others:

record_byte_length : constant := 6;

type Record_Type is record
    field_0 : Integer_16;
    field_1 : Integer_16;
    field_2 : Integer_16;
end record;

for record_type use record
    Field_1 at 0 range 0 .. 15;
    field_2 at 2 range 0 .. 15;
end record;
for record_type'size use record_byte_length * 8;


I forgot to add Field_0 to the rep clause, and the compiler put it at
the end (where it didn't belong). Most importantly, the compiler
didn't warn me.

One solution is to have the compiler write the representation clause
for me; in this case, if we make reasonable assumptions about
'record_type', there is only one reasonable rep clause. So I'd like to
define:

------------
pragma Deduce_Representation (type_local_name);

Specifies that the compiler will assume a record representation clause for
'type_local_name'.

Every component of 'type_local_name' shall be of a type that has an
explicit size attribute.

'type_local_name' shall have an explicit size attribute, which is
equal to the sum of the component sizes.

'type_local_name' shall have an explicit Bit_Order attribute.

The representation clause shall layout the components in declaration
order, using the sizes specified in the corresponding size attribute.
------------


Most of the record representation clauses I write meet these criteria,
and it would prevent maintenance bugs like the above. It would also
save time, and avoid other bugs related to writing rep clauses.

It would be nice if the assumed rep clause could be endianness-independent,
but I suspect that's not possible.

It's important that the typical user be able to predict what rep
clause the compiler will assume, which is why I've required explicit
size attributes on the component types. If we also need to exclude
tagged types or disciminated records, that's ok by me.


-- 
-- Stephe

Re: Default rep specs for record types - documented??

[Britt Snodgrass]

Stephen Leake wrote:
> Stephen Leake <stephen_leake@acm.org> writes:
>

<snip>
>
> One solution is to have the compiler write the representation clause
> for me; in this case, if we make reasonable assumptions about
> 'record_type', there is only one reasonable rep clause. So I'd like to
> define:


Starting with version 4.2 I believe, the Apex Ada editor has a "Build
Rep Clauses" feature that will insert all applicable compiler generated
confirming representation clauses following a type declaration. I've
tried it with Apex NT 4.2.0c and it works nicely.

Here is an example:

    type Record_Type is
        record
            Field_0 : Integer_16;
            Field_1 : Integer_16;
            Field_2 : Integer_16;
        end record;

    for Record_Type use
        record
            Field_0 at 0 range 0 .. 15;
            Field_1 at 2 range 0 .. 15;
            Field_2 at 4 range 0 .. 15;
        end record;
    for Record_Type'Alignment use 4;
    for Record_Type'Size use 48;
    pragma Convention (Ada_Pass_By_Copy, Record_Type);

Everything after the record type declaration was generated by the
compiler and inserted by the editor,

-- Britt

Re: Default rep specs for record types - documented??

[Lauri Ora]

On 2005-11-04, Britt Snodgrass <britt.snodgrass@gmail.com> wrote:
> Starting with version 4.2 I believe, the Apex Ada editor has a "Build
> Rep Clauses" feature that will insert all applicable compiler generated
> confirming representation clauses following a type declaration. I've
> tried it with Apex NT 4.2.0c and it works nicely.

Some versions of GNAT also has option -gnatR1 (List rep info), which 
gives you similar output:
   for Record_Type'Size use 48;
   for Record_Type'Alignment use 2;
   for Record_Type use record
      Field_0 at 0 range  0 .. 15;
      Field_1 at 2 range  0 .. 15;
      Field_2 at 4 range  0 .. 15;
   end record;

Obviously this only gives you the information, and does not touch the
source files.  But these could be used as a starting point.

-Lauri

Re: Default rep specs for record types - documented??

[Larry Kilgallen]

In article <slrndmn0ub.v5k.lauri@dev.diter.com>, Lauri Ora <lauri.ora@iki.fi> writes:
> On 2005-11-04, Britt Snodgrass <britt.snodgrass@gmail.com> wrote:
>> Starting with version 4.2 I believe, the Apex Ada editor has a "Build
>> Rep Clauses" feature that will insert all applicable compiler generated
>> confirming representation clauses following a type declaration. I've
>> tried it with Apex NT 4.2.0c and it works nicely.
> 
> Some versions of GNAT also has option -gnatR1 (List rep info), which 
> gives you similar output:
>    for Record_Type'Size use 48;
>    for Record_Type'Alignment use 2;
>    for Record_Type use record
>       Field_0 at 0 range  0 .. 15;
>       Field_1 at 2 range  0 .. 15;
>       Field_2 at 4 range  0 .. 15;
>    end record;

On VMS, one uses the SDL freeware tool, since for system data structures
it produces layouts matching the layouts for other languages.

Re: Default rep specs for record types - documented??

[Anonymous Coward]

In article <slrndmn0ub.v5k.lauri@dev.diter.com>, Lauri Ora wrote:
> 
> Some versions of GNAT also has option -gnatR1 (List rep info), which 
> gives you similar output:

That is a very useful option.  I wish I had known about it sooner.  Is
there a similar switch for C code?  It would make interface coding so
much easier if I could generate this output for C types before
constructing the corrosponding ADA interface.

Re: Default rep specs for record types - documented??

[Frank J. Lhota]

"Anonymous Coward" <bogus_addy@bogus_domain.net> wrote in message 
news:slrndmod4h.b6j.bogus_addy@tango.mindfuq.org...
> In article <slrndmn0ub.v5k.lauri@dev.diter.com>, Lauri Ora wrote:
>>
>> Some versions of GNAT also has option -gnatR1 (List rep info), which
>> gives you similar output:
>
> That is a very useful option.  I wish I had known about it sooner.  Is
> there a similar switch for C code?  It would make interface coding so
> much easier if I could generate this output for C types before
> constructing the corrosponding ADA interface.

Unfortunately, I know of no C/C++ compiler that generates struct / class 
layout information. Moreover, there is still no C/C++ equivalent of the 
representation clause.

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"

Re: Default rep specs for record types - documented??

[Ed Falis]

On Fri, 04 Nov 2005 21:26:49 -0500, Anonymous Coward  
<bogus_addy@bogus_domain.net> wrote:

> In article <slrndmn0ub.v5k.lauri@dev.diter.com>, Lauri Ora wrote:
>>
>> Some versions of GNAT also has option -gnatR1 (List rep info), which
>> gives you similar output:
>
> That is a very useful option.  I wish I had known about it sooner.  Is
> there a similar switch for C code?  It would make interface coding so
> much easier if I could generate this output for C types before
> constructing the corrosponding ADA interface.


But if you order the components the same in both languages, and use pragma  
Convention (C, ...) on the Ada side, the Ada record layout will match the  
C struct layout.

- Ed

Re: Default rep specs for record types - documented??

[Anonymous Coward]

In article <op.szqzwuei5afhvo@localhost>, Ed Falis wrote:
> 
> But if you order the components the same in both languages, and use
> pragma Convention (C, ...) on the Ada side, the Ada record layout
> will match the C struct layout.

Is that necessarily true?  I've noticed some cases where pragma
Convention (C,...) does not stretch an enum to 32 bits the way it
should, so there seems to be an element of chance that causes me to
distrust it.

Re: Default rep specs for record types - documented??

[Lauri Ora]

Ed Falis wrote:
> On Fri, 04 Nov 2005 21:26:49 -0500, Anonymous Coward  
> <bogus_addy@bogus_domain.net> wrote:
>> In article <slrndmn0ub.v5k.lauri@dev.diter.com>, Lauri Ora wrote:
>>> Some versions of GNAT also has option -gnatR1 (List rep info), which
>>> gives you similar output:
>> That is a very useful option.  I wish I had known about it sooner.  Is
>> there a similar switch for C code?  It would make interface coding so
>> much easier if I could generate this output for C types before
>> constructing the corrosponding ADA interface.
> But if you order the components the same in both languages, and use 
> pragma  Convention (C, ...) on the Ada side, the Ada record layout will 
> match the  C struct layout.

Which types does this work for? Those defined in Interfaces.C?

-Lauri

Re: Default rep specs for record types - documented??

[Ed Falis]

On Fri, 04 Nov 2005 23:07:11 -0500, Lauri Ora <lauri.ora@iki.fi> wrote:

>
> Which types does this work for? Those defined in Interfaces.C?

The minimum and portable set is the types defined in Interfaces.C and  
composite types built up from them according to the rules in RM B.1, paras  
12 - 21.

- Ed

Re: Default rep specs for record types - documented??

[Stephen Leake]

"Ed Falis" <falis@verizon.net> writes:

> But if you order the components the same in both languages, and use
> pragma  Convention (C, ...) on the Ada side, the Ada record layout
> will match the  C struct layout.

This has always bothered me, because it is so poorly defined.

Which C compiler? With which settings of the various layout options?

If I'm compiling with GNAT, I could guess that it's 'gcc' and 'the
defaults'; but the point of rep clauses is to not guess. 

But if I'm compiling with GNAT and trying to interface to Borland C
with the equivalent of 'pack structs', it's just plain wrong.

On VAX and Alpha, this might have some meaning, because DEC defined a
binary API. But on x86, it's just a guess.

-- 
-- Stephe

Re: Default rep specs for record types - documented??

[Frank J. Lhota]

Stephen Leake wrote:
> I've submitted the following to AdaCore:
> 
> I had a record:
> 
> record_byte_length : constant := 4;
> 
> type Record_Type is record
>     field_1 : Integer_16;
>     field_2 : Integer_16;
> end record;
> 
> for record_type use record
>     Field_1 at 0 range 0 .. 15;
>     field_2 at 2 range 0 .. 15;
> end record;
> for record_type'size use record_byte_length * 8;

I would recommend writing the 'Size rep clause as follows:

	for record_type'size use 2 * Integer_16'Size;

Then we can skip the record_byte_length declaration.

> Then I needed to add a field, which should go before the others:
> 
> record_byte_length : constant := 6;
> 
> type Record_Type is record
>     field_0 : Integer_16;
>     field_1 : Integer_16;
>     field_2 : Integer_16;
> end record;
> 
> for record_type use record
>     Field_1 at 0 range 0 .. 15;
>     field_2 at 2 range 0 .. 15;
> end record;
> for record_type'size use record_byte_length * 8;
> 
> 
> I forgot to add Field_0 to the rep clause, and the compiler put it at
> the end (where it didn't belong). Most importantly, the compiler
> didn't warn me.

The fault lies with the code, not the compiler. Where in this code is 
there any indication that Field_0 "does not belong" at the end? This 
representation clause requires that Field_1 and Field_2 occupy the first 
four bytes of the record, so where else *could* the compiler place 
field_0 besides the end?

The raison d'�tre behind record representation clauses is to make sure 
that a record layout matches some external data format. For internal 
data, you would be better off forgoing the representation clauses and 
letting the compiler choose the optimal record layout.

Now the Ada compiler cannot possibly know anything about external data 
formats. The programmer must therefore be especially careful in coding 
the representation clause, for this is the compiler's only clue as to 
the desired record layout. Writing a bad representation clause is one of 
the errors that the compiler cannot reasonably protect the protect the 
programmer from making.

> One solution is to have the compiler write the representation clause
> for me; in this case, if we make reasonable assumptions about
> 'record_type', there is only one reasonable rep clause. 

Both ObjectAda and GNAT have options by which Ada representation clauses 
are generated for all record declarations in the sources. These compiler 
generated representation clauses can serve as a good starting point, but 
it is still up to the programmer to make the needed modifications in 
order to get the required data layout.

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"

Re: Default rep specs for record types - documented??

[Frank J. Lhota]

Frank J. Lhota wrote:
> Writing a bad representation clause is one of 
> the errors that the compiler cannot reasonably protect the protect the 
                                                  ^^^^^^^^^^^^
.. And duplicating a few words is one of those errors that the spell 
checker cannot reasonably protect the writer from making! Sorry.

> programmer from making.


-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"

Re: Default rep specs for record types - documented??

[tmoran]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

> The raison d'�tre behind record representation clauses is to make sure
> that a record layout matches some external data format. For internal
> data, you would be better off forgoing the representation clauses and
> letting the compiler choose the optimal record layout.
    Absolutely.  Alignment can make a substantial performance difference
on some machines, so re-ordering or inserting padding will be an
optimization.  If you insert a rep spec where it really isn't needed
(whether a hand or compiler or tool generated one) it may prevent
valuable, and non-obvious, optimization when the program is recompiled
for a different CPU.  IIRC, at least one Ada compiler, given
  type R is record
    A : integer;
    B : integer range 40 .. 40 := 40;
    C : integer;
  end record;
allocated zero bits for B since its value was known to be a constant 40.
Underspecifying can be erroneous, but overspecifying can also have bad
results.

Re: Default rep specs for record types - documented??

[Stephen Leake]

"Frank J. Lhota" <NOSPAM.lhota@adarose.com> writes:

> Stephen Leake wrote:

>> I forgot to add Field_0 to the rep clause, and the compiler put it at
>> the end (where it didn't belong). Most importantly, the compiler
>> didn't warn me.
>
> The fault lies with the code, not the compiler. 

No, the fault lies with me, who wrote the code. The code is, as you
point out, wrong.

Part of the point of using Ada is to make it harder to make mistakes
like this. That's why I want a warning when I make this mistake.

> Where in this code is there any indication that Field_0 "does not
> belong" at the end? This representation clause requires that Field_1
> and Field_2 occupy the first four bytes of the record, so where else
> *could* the compiler place field_0 besides the end?

Of course; that is the point of rep clauses. Which is why the code is
wrong.

> The raison d'�tre behind record representation clauses is to make sure
> that a record layout matches some external data format. For internal
> data, you would be better off forgoing the representation clauses and
> letting the compiler choose the optimal record layout.

This is _not_ internal data; that's why there is a rep clause.

> Now the Ada compiler cannot possibly know anything about external data
> formats. The programmer must therefore be especially careful in coding
> the representation clause, for this is the compiler's only clue as to
> the desired record layout. Writing a bad representation clause is one
> of the errors that the compiler cannot reasonably protect the protect
> the programmer from making.

The compiler can't protect me entirely, but it can easily warn me
about this particular mistake; leaving a component out of the rep
clause.

Compare this to a case statement on an enumeration type; the compiler
warns you when you add an enumeral but forget to update the case
statement.

Programmers should be careful, but the compiler should help whenever
it reasonably can.

>> One solution is to have the compiler write the representation clause
>> for me; in this case, if we make reasonable assumptions about
>> 'record_type', there is only one reasonable rep clause.
>
> Both ObjectAda and GNAT have options by which Ada representation
> clauses are generated for all record declarations in the sources.
> These compiler generated representation clauses can serve as a good
> starting point, but it is still up to the programmer to make the
> needed modifications in order to get the required data layout.

Right, and I could integrate that with Emacs. But I'd rather go all
the way and have the compiler do everything for me.

More importantly, I want the compiler to generate the "reasonable
packed rep clause", not "the most efficient for data storage" or
whatever other criteria it uses in the absence of a rep clause. 

This matters more when I'm describing bit fields in a register;
without a rep clause the compiler will use at least a byte for each
field. So the generated rep clause will not be a very good starting
point.

-- 
-- Stephe

Re: Default rep specs for record types - documented??

[Robert A Duff]

Stephen Leake <stephen_leake@acm.org> writes:

> "Frank J. Lhota" <NOSPAM.lhota@adarose.com> writes:
> 
> > Stephen Leake wrote:
> 
> >> I forgot to add Field_0 to the rep clause, and the compiler put it at
> >> the end (where it didn't belong). Most importantly, the compiler
> >> didn't warn me.
> >
> > The fault lies with the code, not the compiler. 
> 
> No, the fault lies with me, who wrote the code. The code is, as you
> point out, wrong.
> 
> Part of the point of using Ada is to make it harder to make mistakes
> like this. That's why I want a warning when I make this mistake.

I agree.  It would be better if you had to explicitly say
"I don't care about field X" if you don't, and the compiler
would complain if you just leave X out of the rep clause.

I'm not even sure the capability to leave out some components is useful
enough to have in the language.

> Compare this to a case statement on an enumeration type; the compiler
> warns you when you add an enumeral but forget to update the case
> statement.

Right, or a record aggregate where you add a component.

> More importantly, I want the compiler to generate the "reasonable
> packed rep clause", not "the most efficient for data storage" or
> whatever other criteria it uses in the absence of a rep clause. 

That would be nice.  Record rep clauses are way too detailed for most
uses.  There ought to be a way to say "use the canonical
representation".

> This matters more when I'm describing bit fields in a register;
> without a rep clause the compiler will use at least a byte for each
> field. So the generated rep clause will not be a very good starting
> point.

You could say "pragma Pack", and then see what the compiler says.

But once you've included the rep clause in your source code, it becomes
difficult to maintain, whether it was compiler generated or hand
written.

- Bob

Re: Default rep specs for record types - documented??

[Anonymous Coward]

In article <uacgktuhd.fsf@acm.org>, Stephen Leake wrote:
>>
>> What's disappointing is that rep specs add considerable clutter.
> 
> Yes. Ada explicitly favors being precise over being concise.

Precision need not be at odds with conciseness.  Consider an
enumerated type:

  type my_enum is (first, second, third);

I am *guaranteed* by the LRM that the representation will code "first"
as zero, "second" as 1, and "third" as 2.  Adding this rep spec:

  for my_enum use (first => 0, second => 1, third => 2);

gives me no more precision, yet it dirties the code.  

Consequently, I will never rep spec an enum unless I intend to deviate
from the default rep spec.  And when I do deviate, the code will be
more readable, because the reader will say "hey wait a minute, why is
this rep spec'd and the others are not.. hmm.. there's something
different here.."  So differences will stand out, as they should.

So being able to count on default representations (which are
changable) is a good thing, because you can be both precise and
concise.

However, in the case of records, I've changed my opinion based on what
I've read here.  A compiler should be given opportunity to optimize
where practical, and imposing a default rep spec could hinder the
compilers ability to optimize record layout.

>> Readable code avoids redundancy, so having default representation
>> aspects that are guaranteed enable less noisey code. 
> 
> Representation clauses are not 'redundant'; they provide information
> that is not provided by the type declaration.

That seems to depend on what aspect of what kind of type we're talking
about.  In the enum case above, the "for .. use" rep spec *is*
redundant.  

> One problem is that the compiler does _not_ warn you if you leave a
> component out of the rep clause; a 'pragma Complete_Representation'
> would be nice. Specifying the total size can mitigate this, but I
> recently had a bug due to this problem.

I can think of cases where rep spec'ing partial records would be
useful.  But I would agree that there should certainly be a warning.

>> I'm not looking forward to rep specing records bit for bit simply to
>> enforce the same order of elements that's specified in the operation
>> specs.
> 
> If 'operation specs' are defining the hardware you are interfacing
> to, then yes, you need a rep clause for each hardware register. The
> time spent writing those clauses _will_ be repaid later when it
> comes to testing on the hardware; there _will_ be fewer bugs.

Perhaps, but for interfacing with C operations (which is my case), I
would prefer to simply write "pragma convention (C, my_record)" and be
able to expect the compiler to base the representational spec purely
off the operational spec, just as the C compiler would for a structure
that only has an operational spec.  

I should not have to micromanage the bitwise layout of a record to
interface with C code.  It puts me at a lower level, and positions me
to make human errors (like writing an incomplete rep spec for a
record), when such errors can be avoided by keeping it high level.

> Someone mentioned a 'pragma Preserve_Layout', which presumably means
> "assume a representation clause that puts things in declaration order,
> with the base size for each component, and no gaps". That would be
> useful, in situations where the type declarations do in fact match the
> hardware precisely. Hmm. That is true for most of the rep clauses I've
> written recently. I'll have to suggest that to AdaCore as a possible
> enhancement; it would have prevented my bug. 

Yes, I agree.. that would be useful.  Or maybe better yet, mandate
that pragma convention (C,...) matches representation order to
declaration order to keep the number of pragmas minimal.

Re: Default rep specs for record types - documented??

[Stephen Leake]

Anonymous Coward <bogus_addy@bogus_domain.net> writes:

>>> I'm not looking forward to rep specing records bit for bit simply to
>>> enforce the same order of elements that's specified in the operation
>>> specs.
>> 
>> If 'operation specs' are defining the hardware you are interfacing
>> to, then yes, you need a rep clause for each hardware register. The
>> time spent writing those clauses _will_ be repaid later when it
>> comes to testing on the hardware; there _will_ be fewer bugs.
>
> Perhaps, but for interfacing with C operations (which is my case), I
> would prefer to simply write "pragma convention (C, my_record)" and be
> able to expect the compiler to base the representational spec purely
> off the operational spec, just as the C compiler would for a structure
> that only has an operational spec.  

If by 'C', your Ada compiler means your C compiler, this will work. 

> I should not have to micromanage the bitwise layout of a record to
> interface with C code.  It puts me at a lower level, and positions me
> to make human errors (like writing an incomplete rep spec for a
> record), when such errors can be avoided by keeping it high level.

Which is why 'convention (C)' is available. 

> <snip>  Or maybe better yet, mandate
> that pragma convention (C,...) matches representation order to
> declaration order to keep the number of pragmas minimal.

Hmm. You seem to be saying "convention (C) doesn't work for me". That
seems like a bug. Can you post some code that doesn't work? Or have
you submitted a bug report?

-- 
-- Stephe

ADA/C interfaces: type representations uncontrollable in C

[Anonymous Coward]

In article <uk6fn758i.fsf@acm.org>, Stephen Leake wrote:
> 
> Hmm. You seem to be saying "convention (C) doesn't work for
> me". That seems like a bug. Can you post some code that doesn't
> work? Or have you submitted a bug report?

I should start by saying that I think the compiler I witnessed this on
is version 3.15p.  I'll have to check on that.

The pragma convention anomaly I've noticed relates to enums, not
records.  However, just because records have been represented in a
sequence of elements that matches the operational spec doesn't mean I
can count on it to work every time - it may have been chance.

I'm beginning to realize that it's impossible to write compiler
independant ADA code if it must interface with C code.  Even rep
spec'ing down to the bitwise rep specs makes no guarantess that the
chosen layout will match what all C compilers produce (since they can
potentially all be different).

What I don't understand is how GNAT can give the user representation
control over types, when C does not, considering that GNAT translates
ADA to C.  How does GNAT perform that intermediate C translation if
rep specs don't exist in C?

Re: ADA/C interfaces: type representations uncontrollable in C

[Ed Falis]

On Sat, 05 Nov 2005 11:35:51 -0500, Anonymous Coward  
<bogus_addy@bogus_domain.net> wrote:

> What I don't understand is how GNAT can give the user representation
> control over types, when C does not, considering that GNAT translates
> ADA to C.  How does GNAT perform that intermediate C translation if
> rep specs don't exist in C?


GNAT doesn't translate to C; it translates to the gcc intermediate form  
that is also used by other languages that are part of gcc (GNU Compiler  
Collection).

- Ed

Re: ADA/C interfaces: type representations uncontrollable in C

[tmoran]

> I'm beginning to realize that it's impossible to write compiler
> independant ADA code if it must interface with C code.  Even rep
> spec'ing down to the bitwise rep specs makes no guarantess that the
> chosen layout will match what all C compilers produce (since they can
> potentially all be different).
   Yes, "it's impossible to write compiler independant" C code since
C compilers can potentially all be different.
   More commonly you are interfacing to an existing C system, which
is compiled with a particular C compiler, eg, Windows and MS C++.
In that case there is a non-moving target and you can write Ada code
that is nearly* independent of the particular Ada compiler.
   *Particular Ada compilers have quirks and bugs that you may have to
get around in different ways.  CLAW's rep spec clauses for instance
work fine with MS Windows, but there are a few other things where there's
different code for different Ada compilers, and one of the tasks is
keeping up with the latest versions of compilers.

'Size can mean value size OR object size, depending..

[Anonymous Coward]

In article <uk6fn758i.fsf@acm.org>, Stephen Leake wrote:
> 
> Hmm. You seem to be saying "convention (C) doesn't work for
> me". That seems like a bug. Can you post some code that doesn't
> work? Or have you submitted a bug report?

I explored this issue a little more, and it looks like it was my
error.  I thought 'Size returned the object size, not the value size!
To top it off, I was using GNAT 2.8.1, which does not have a
-gnatR[1-3] switch.  If it did, this it would have clearly given me
this output for my enum:

   $ gcc -c -gnatR3 main.adb
    
   Representation information for unit Main (body)
   -----------------------------------------------
    
   for Entity_Type'Object_Size use 32;
   for Entity_Type'Value_Size use 2;
   for Entity_Type'Alignment use 4;

   $ gcc --version
   gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

(as you can see, later versions of GNAT support 
 enum representation printing) 

So at work I was reliant on 'Size to tell me how large the enum is,
not knowing until now that 'Object_Size is really an attribute
operation.  I thought 'Object_Size was just gnats way of making the
distinction.  

So this code:

   with Ada.Text_Io;

   procedure Main is

      type Entity_Type is (Red, Green, Blue);

      pragma Convention (Convention => C, Entity => Entity_Type);

      --In this case, 'Size really means the *object* size!
      --
      --for Entity_Type'Size use 32; --not needed with convention C!

   begin

      Ada.Text_Io.Put_Line ("The object size is " & 
                            Integer'Image(Entity_Type'Object_Size));

      --ADA throws a curve ball here, by changing the meaning of 'Size
      --to actually indicate the *value* size in this case!
      --
      Ada.Text_Io.Put_Line ("The value size is "  & 
                            Integer'Image(Entity_Type'Size));

   end Main;

generates:

   The object size is  32
   The value size is  2

proving that pragma convention effectively works on enumeration
types.  So in the interest of writing clean code, I do not intend to
rep spec enum sizes anymore, because pragma Convention takes care of
this from a higher level.

Re: 'Size can mean value size OR object size, depending..

[Jeffrey R. Carter]

Anonymous Coward wrote:

> So at work I was reliant on 'Size to tell me how large the enum is,
> not knowing until now that 'Object_Size is really an attribute
> operation.  I thought 'Object_Size was just gnats way of making the
> distinction.  

Note that 'Object_Size is GNAT specific. The portable way to obtain this value 
is to use 'Size on an object:

X : T;

X'Size

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus
21

Re: 'Size can mean value size OR object size, depending..

[Anonymous Coward]

In article <E0ecf.1856$Id6.503@newsread1.news.pas.earthlink.net>, 
Jeffrey R. Carter wrote:
> 
> Note that 'Object_Size is GNAT specific. The portable way to obtain
> this value is to use 'Size on an object:
> 
> X : T;
> 
> X'Size

That's interesting!  I would not have expected ADA to even allow
compilers to offer their own attributes like that.  It seems like a
bad thing.  Folks could unwittingly write GNAT only code, which would
break later on if a different compiler is chosen.

For the archives, here's a complete example that includes Jeff's
comment:

   with Ada.Text_Io;

   procedure Size_Example is

      type Color_Type is (Red, Green, Blue);

      pragma Convention (Convention => C, Entity => Color_Type);

      --In this case, 'Size really means the *object* size!
      --
      --for Entity_Type'Size use 32; --not needed with convention C!

      Color_Object : Color_Type := Color_Type'First;

   begin

      --GNAT *uniquely* offers a 'Object_Size attribute,
      --so the following line is not ADA!
      --
      Ada.Text_Io.Put_Line ("The object size is " &
                            Integer'Image(Color_Type'Object_Size) &
                            " GNAT only!");

      --ADA does not provide an attribute to get the object size of a type.
      --You can only acquire this by doing a 'Size directly on an object:
      --
      Ada.Text_Io.Put_Line ("The object size is " &
                            Integer'Image(Color_Object'Size));

      --ADA throws a curve ball here, by changing the meaning of 'Size
      --to actually indicate the *value* size in this case!
      --
      Ada.Text_Io.Put_Line ("The value size is " &
                            Integer'Image(Color_Type'Size));

   end Size_Example;

Output:

   The object size is  32 GNAT only!
   The object size is  32
   The value size is  2

Re: Default rep specs for record types - documented??

[Michael Bode]

Anonymous Coward <bogus_addy@bogus_domain.net> writes:

> Perhaps, but for interfacing with C operations (which is my case), I
> would prefer to simply write "pragma convention (C, my_record)" and be
> able to expect the compiler to base the representational spec purely
> off the operational spec, just as the C compiler would for a structure
> that only has an operational spec.  

But then you should be able to specify *which* C Compiler. That is which
brand and version number, otherwise your Ada compiler is just
guessing. E.g. the specification of type bool has changed for MS C
somewhere around version 4.2 from 32 bits to 8 bits.

-- 
Michael Bode

pragma convention

[Anonymous Coward]

In article <87y8435fve.fsf@code-hal.de>, Michael Bode wrote:
> Anonymous Coward <bogus_addy@bogus_domain.net> writes:
> 
>> Perhaps, but for interfacing with C operations (which is my case),
>> I would prefer to simply write "pragma convention (C, my_record)"
>> and be able to expect the compiler to base the representational
>> spec purely off the operational spec, just as the C compiler would
>> for a structure that only has an operational spec.
> 
> But then you should be able to specify *which* C Compiler. That is
> which brand and version number, otherwise your Ada compiler is just
> guessing. E.g. the specification of type bool has changed for MS C
> somewhere around version 4.2 from 32 bits to 8 bits.

You raise a good point, assuming C compilers all have the freedom to
represent types arbitrarily.  So what's the point of the current
existence of pragma Convention?  What can I expect pragma convention
to do for me?

Re: pragma convention

[Jeffrey R. Carter]

Anonymous Coward wrote:

> You raise a good point, assuming C compilers all have the freedom to
> represent types arbitrarily.  So what's the point of the current
> existence of pragma Convention?  What can I expect pragma convention
> to do for me?

pragma Convention (X, ...

really means the convention used by some specific X compiler chosen by the Ada 
compiler developers for those cases where the X language does not rigorously 
specify the characteristic in question.

Convention C does do certain common things for you. For an access type, you 
insure that it is just a pointer, and doesn't contain any additional data (which 
Ada's access values can and sometimes do contain). For subprograms, you get 
automatic conversion of parameters to pointers to match C passing rules and make 
[in] out parameters work properly.

This latter is very useful; you can write

procedure C (X : out Interfaces.C.Int);
pragma Import (C, X, "xInC");

and the compiler takes care of passing a pointer for you.

-- 
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail
10

Re: pragma convention

[Anonymous Coward]

In article <cHcbf.204$c_1.175@newsread3.news.pas.earthlink.net>, 
Jeffrey R. Carter wrote:
> 
> pragma Convention (X, ...
> 
> really means the convention used by some specific X compiler chosen
> by the Ada compiler developers for those cases where the X language
> does not rigorously specify the characteristic in question.

I find it interesting that pragma Convention even appears in the ARM,
considering there is no definite behavior required for it.  It seems
it would be more appropriate to not even mention it in the ARM, and
let the compiler implementors decide whether to have it.  Or if pragma
Convention should be mentioned in the ARM, it should be rewritten.  I
would rewrite this:

   ARM B.1.21

   If pragma Convention applies to a type, then the type shall either
   be compatible with or eligible for the convention specified in the
   pragma.

to state something like:

   If pragma Convention applies to a type, then the type shall be
   compatible with conventions specified in the pragma for languages
   that have a convention.  For other languages, pragma Convention is
   to be offered at the discretion of the compiler authors.

From there, it would be useful to have a list of languages that have
default representations, so ADA programmers know when they can expect
some precise behavior from pragma convention.

> Convention C does do certain common things for you. For an access
> type, you insure that it is just a pointer, and doesn't contain any
> additional data (which Ada's access values can and sometimes do
> contain). 

That's useful to know.. but why doesn't the ARM lay down the rule on
that?  It seems largely like guesswork to know what to expect from
pragma convention.

Is there a way to explicitly define a pointer in ADA to be a raw
address as it is for C, without the pragma convention?  Is that what
system.address is?  

> For subprograms, you get automatic conversion of parameters to
> pointers to match C passing rules and make [in] out parameters work
> properly.
> 
> This latter is very useful; you can write
> 
> procedure C (X : out Interfaces.C.Int);
> pragma Import (C, X, "xInC");
> 
> and the compiler takes care of passing a pointer for you.

Parameter modes are handled entirely by pragma import, correct?  I'm
not sure what pragma convention does in that respect.

Someone stated earlier that pragma convention will ensure order is
preserved for records types passed to pragma convention, but the GNAT
manual states that pragma Convention has no effect on records:

http://gcc.gnu.org/onlinedocs/gcc-3.3.5/gnat_rm/Effect-of-Convention-on-Representation.html

I find it frustrating to work with loosely defined characteristics in
ADA.  At this point, I'll continue to use pragma convention for the
heck of it, but ultimately it seems I cannot solely rely on it to do
anything, and I should be rep specing records and enum sizes anyway.

Re: pragma convention

[Jeffrey R. Carter]

Anonymous Coward wrote:

> Is there a way to explicitly define a pointer in ADA to be a raw
> address as it is for C, without the pragma convention?  Is that what
> system.address is?  

No. It's possible for an access value, a convention-C pointer, and a 
System.Address to be 3 different things. However, it's rare for a C pointer and 
a System.Address to be different.

> Someone stated earlier that pragma convention will ensure order is
> preserved for records types passed to pragma convention, but the GNAT
> manual states that pragma Convention has no effect on records:
> 
> http://gcc.gnu.org/onlinedocs/gcc-3.3.5/gnat_rm/Effect-of-Convention-on-Representation.html

What this says about record representations is that GNAT's default 
representation for a record is the same as C's (gcc's, specifically), so for 
GNAT, specifying convention C for a record doesn't change anything because the 
representation is already convention C.

-- 
Jeff Carter
"C's solution to this [variable-sized arrays] has real problems,
and people who are complaining about safety definitely have a point."
Dennis Ritchie
25

Re: Default rep specs for record types - documented??

[Martin Krischik]

Am 05.11.2005, 05:33 Uhr, schrieb Anonymous Coward  
<bogus_addy@bogus_domain.net>:

> Perhaps, but for interfacing with C operations (which is my case), I
> would prefer to simply write "pragma convention (C, my_record)" and be
> able to expect the compiler to base the representational spec purely
> off the operational spec, just as the C compiler would for a structure
> that only has an operational spec.

Well, it should actualy work - unless you use an incompatible C compiler.  
You see: pragma convention (C... will only work with the appropiate sister  
C compiler. In case of GNAT it is the gcc.

Problem is that most C compiler will unpack records in order to speed up  
access to the data. That is so ever since we moved from 8 bit CPUs to  
16bit CPUs and accessing an even address became faster then accessing an  
odd address. On 32 bit CPUs data might even be unpacked to addresses which  
can be devided by 4. or 8 on 64 bit CPUs.

Or not at all since modern MMU (Memeory Management Units) and multiple  
cache buffer might make accessing an odd address just as fast then an even  
address reverting the hole trent again.

It's all a big maybe. And you might even get that trouble when you are  
using 2 diffrent C compilers. Like a 3rd party lib compiled with C  
compiler 1 optimizing for i386 and you use C compiler 2 optimizing for  
x86_64.

Most C compilers have "#pragma pack (...)" to solve the mess. And Ada has  
"for Record_Type'Alignment use ...;"

Martin

Re: Default rep specs for record types - documented??

[Martin Dowie]

Steve wrote:
> So... if it matters, use a representation clause.

The old Ada83 Telegen2 compiler used to come with a handy "pragma
Preserve_Layout" addition. Large rep clauses always look so ugly! :-)

Cheers

-- Martin

Re: Default rep specs for record types - documented??

[Marc A. Criley]

Steve wrote:
> "Anonymous Coward" <bogus_addy@bogus_domain.net> wrote in message 
> news:slrndmloee.kq0.bogus_addy@tango.mindfuq.org...
> 
>>I'm interested in finding out what the default representation of a
>>record type is.  Can I expect the sequence of elements in the default
>>representation to match the sequence they are defined in?
>>
> 
> Look in the Ada 95 LRM section 13, Representation Issues
> 
> Section 13.1 paragraph 19
> 
> If an aspect of representation of an entity is not specified, it is chosen 
> by default in an unspecified manner.
> 
> So... if it matters, use a representation clause.

Another way to do this, if you just want to guarantee component 
ordering, and you don't mind some extra padding possibly being added 
into the record instances, is to apply pragma Convention (C, ...) to the 
record.

While that convention is (obviously) nominally intended for interfacing 
to external C software, it has the desired effect of preventing 
reordering of record components.

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: Default rep specs for record types - documented??

[Martin Krischik]

Am 04.11.2005, 04:21 Uhr, schrieb Anonymous Coward  
<bogus_addy@bogus_domain.net>:

> I'm interested in finding out what the default representation of a
> record type is.  Can I expect the sequence of elements in the default
> representation to match the sequence they are defined in?

Whatever works best for the CPU at hand. The compiler has complete freedom  
for any optimization usefull. He can pack them or align them, reorder -  
what ever give best perfomace. Or he doesn't do any of that because there  
is nor record layout optimizer implemented in the Ada compiler of your  
choice.

Also read:

http://en.wikibooks.org/wiki/Ada_Programming/Types/record#With_aliased_elements

Martn