Representation clauses and streams

Representation clauses and streams

[Florian Weimer]

I understand that, according to the ARM, record representation clauses
have to be ignored by the default implementations for 'Read and 'Write
(13.13.2(9)).  But representation clauses are ignored for discrete
types as well (at least by GNAT 3.12p on x86).  For example, the type

   Bits_Per_Octet : constant := 8;

   type One_Octet_Type   is range 0 .. 2**(1*Bits_Per_Octet) - 1;
   for One_Octet_Type'Size use Bits_Per_Octet;

is written as a two-octet value to a stream (Stream_Element'Size is,
of course, 8).  One_Octet_Type'Object_Size and One_Octet_Type'Value_Size
(the non-standard GNAT pragmas) are 8 as well; so I'm pretty sure that
a value of type One_Octet_Type should fit into one Stream_Element.

Well, I don't like this behavior at all.  Is there any reason why GNAT
ignores the implementation advice 13.13.2(17)?  What are other compilers
doing here?

A short package for testing (of course, it doesn't run, you have to
look at the machine code to see which of the predefined write operations
is performed):

with Ada.Streams;
package Test_Rep is
   
   Bits_Per_Octet : constant := 8;
   
   type One_Octet_Type is range 0 .. 2**(1*Bits_Per_Octet) - 1;
   for One_Octet_Type'Size use 1*Bits_Per_Octet;
   
   procedure Write
     (Stream : access Ada.Streams.Root_Stream_Type'Class;
      Item   : in One_Octet_Type);
   
end Test_Rep;

package body Test_Rep is

   procedure Write
     (Stream : access Ada.Streams.Root_Stream_Type'Class;
      Item   : in One_Octet_Type)
   is
   begin
      One_Octet_Type'Write (Stream, Item);
   end Write;

end Test_Rep;

Re: Representation clauses and streams

[Ted Dennison]

Florian Weimer wrote:

> types as well (at least by GNAT 3.12p on x86).  For example, the type
>
>    Bits_Per_Octet : constant := 8;
>
>    type One_Octet_Type   is range 0 .. 2**(1*Bits_Per_Octet) - 1;
>    for One_Octet_Type'Size use Bits_Per_Octet;
>
> is written as a two-octet value to a stream (Stream_Element'Size is,

Hmm. I'm curious what would happen if you changed that type to a modular
type of the same range.

--
T.E.D.

Home - mailto:dennison@telepath.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html

Re: Representation clauses and streams

[Florian Weimer]

Ted Dennison <dennison@telepath.com> writes:

> >    Bits_Per_Octet : constant := 8;
> >
> >    type One_Octet_Type   is range 0 .. 2**(1*Bits_Per_Octet) - 1;
> >    for One_Octet_Type'Size use Bits_Per_Octet;
> >
> > is written as a two-octet value to a stream (Stream_Element'Size is,
> 
> Hmm. I'm curious what would happen if you changed that type to a modular
> type of the same range.

It works, thanks. In fact, it seems as if GNAT takes the sign bit into
account, which is, in my eyes, quite unnecessary.

Re: Representation clauses and streams

[Robert Dewar]

In article <tgso0lg67p.fsf@mercury.rus.uni-stuttgart.de>,
  Florian Weimer <Florian.Weimer@rus.uni-stuttgart.de> wrote:
> Well, I don't like this behavior at all.

Then you should submit a comment, this is the required behavior
as specified in the RM.

> Is there any reason why GNAT
> ignores the implementation advice 13.13.2(17)?

GNAT is NOT ignoring this advice

> What are other compilers doing here?

At least one other compiler gets this wrong. We have been
discussing in the ARG whether to modify the RM rules in this
area to give something more to your liking :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Representation clauses and streams

[Florian Weimer]

Robert Dewar <robert_dewar@my-deja.com> writes:

> > Is there any reason why GNAT
> > ignores the implementation advice 13.13.2(17)?
> 
> GNAT is NOT ignoring this advice

Yes, you're right.  I missed the words `base range' (or didn't understand
their implications).  I'm sorry about that.

Re: Representation clauses and streams

[Tucker Taft]

Florian Weimer wrote:
> 
> Robert Dewar <robert_dewar@my-deja.com> writes:
> 
> > > Is there any reason why GNAT
> > > ignores the implementation advice 13.13.2(17)?
> >
> > GNAT is NOT ignoring this advice
> 
> Yes, you're right.  I missed the words `base range' (or didn't understand
> their implications).  I'm sorry about that.

As Robert mentioned, this implementation advice is in the middle
of revision by the Ada Rapporteur Group (ARG) of the ISO Working
Group 9.  The new advice will specify the "first subtype range"
rather than the "base range," as the first subtype range is
portable across implementations, and seems to match users' expectations
better.  

Note that this will mean that certain values of
the "base" subtype T'Base may raise Constraint_Error when
passed to T'Write.  This is currently felt by the ARG to be a reasonable
tradeoff.  Apparently GNAT has not yet been revised to
follow the updated advice, which is quite reasonable given
that the associated AI, AI-195, is still a work-item -- it
is not yet officially "approved."  For the full AI, see:

    http://www.ada-auth.org/cgi-bin-acats/cvsweb.cgi/AIs/AI-00195.DOC

and select revision 1.10.

-Tucker Taft  stt@averstar.com

Re: Representation clauses and streams

[Robert Dewar]

In article <386F900C.235952C2@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> Apparently GNAT has not yet been revised to
> follow the updated advice, which is quite reasonable given
> that the associated AI, AI-195, is still a work-item -- it
> is not yet officially "approved."  For the full AI, see:

And indeed we will have to consider carefully how to deal with
this, since changing to meet the new advice is a non-upwards
compatible change which is sure to cause chaos for many of our
users. So we have not decided what to do about this yet.

Apparently some other compilers failed to follow the RM advice
in the first place, which is what is giving rise to the push
to revise the language here. A tricky situation ....



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Representation clauses and streams

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Apparently some other compilers failed to follow the RM advice
> in the first place, which is what is giving rise to the push
> to revise the language here. 

I don't think other compilers failed to follow the RM advice.  I think
what happened is that different compilers chose different base ranges,
so even if all compilers follow the Advice, they don't all get the same
answer.  Users griped about this, which caused the ARG to get involved.

> A tricky situation ....

Indeed.

- Bob

Re: Representation clauses and streams

[Robert Dewar]

In article <wcc3dsf9xrn.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> > Apparently some other compilers failed to follow the RM
advice
> > in the first place, which is what is giving rise to the push
> > to revise the language here.
>
> I don't think other compilers failed to follow the RM advice.
I think
> what happened is that different compilers chose different base
ranges,
> so even if all compilers follow the Advice, they don't all get
the same
> answer.  Users griped about this, which caused the ARG to get
involved.


That's quite right, some compilers used different base ranges.
Sorry for getting this confused in my previous post.

I actually think that we are mostly OK here. I think that
GNAT basically will do the right thing according to the modified
IA with changes after all (I was confused on this point).

Here is the specific case.

If you say

   type x is range -128 .. +127;
   for x'size use 8;

then (actually with or without the size clause), both the
base type and the first subtype are 8 bits, so GNAT stream
I/O uses 8 bits as expected.

Some other compiler legitimately, but not very helpfully in
this case, chose a base of 32 bits for type x above, and as
a result used four bytes for the stream which was not what
was wanted.

So I think there is no problem with GNAT here after all, or
more properly, the adjustment to GNAT to "agree" with the
new IA will not have a major impact.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Representation clauses and streams

[Robert Dewar]

In article <87k8lq2t4z.fsf@deneb.cygnus.argh.org>,
  Florian Weimer <fw@deneb.cygnus.argh.org> wrote:
> Since everybody seems to have strong feelings about this
issue, I'm
> going to ask only one question:  Why is IA 13.13.2(17)
considered
> so important?  Even if compilers converge on this specific
issue, this
> won't give us portable data streams.  It might make the stream
layout of
> similar targets (that is, architecture and compiler
combinations) a bit
> more similar, but then it doesn't cover the little/big endian
problem.
> And it doesn't seem to be very helpful when you have to match
a given
> data format.


Your barking up the wrong tree here. This IA is not at all
intended to deal with these issues, and indeed it is a good
idea if compilers DO address these issues, and they are
free to (e.g. the XDR implementation in GNAT).

The point is to get reasonably expected behavior for simple
binary I/O on a single target (e.g. I stream out a char, I
want 8 bits, I stream out an int, I want 32 bits).



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Representation clauses and streams

[Florian Weimer]

Tucker Taft <stt@averstar.com> writes:

> For the full AI, see:
> 
>     http://www.ada-auth.org/cgi-bin-acats/cvsweb.cgi/AIs/AI-00195.DOC
> 
> and select revision 1.10.

Thanks!  It is a bit comforting that others are irritated by 13.13 as
well. ;)

Since everybody seems to have strong feelings about this issue, I'm
going to ask only one question:  Why is IA 13.13.2(17) considered
so important?  Even if compilers converge on this specific issue, this
won't give us portable data streams.  It might make the stream layout of
similar targets (that is, architecture and compiler combinations) a bit
more similar, but then it doesn't cover the little/big endian problem.
And it doesn't seem to be very helpful when you have to match a given
data format.