comp.lang.ada
 help / color / mirror / Atom feed
* GNAT bug with respect to an Implementation Advise
@ 2000-12-13 15:53 Jeff Creem
  2000-12-13 19:56 ` Florian Weimer
  2000-12-14  1:40 ` Robert Dewar
  0 siblings, 2 replies; 7+ messages in thread
From: Jeff Creem @ 2000-12-13 15:53 UTC (permalink / raw)


The LRM has an implementation advice that says:

13.13.2(17): Stream Oriented Attributes

If a stream element is the same size as a storage element, then the normal
in-memory representation should be used by Read and Write for scalar
objects. Otherwise, Read and Write should use the smallest number of stream
elements needed to represent all values in the base range of the scalar
type.

To which the GNAT RM says

Followed.

It appears to me that unsigned integers created by means other than modular
types to not follow this rule.

Given the following program :


with Ada.Streams.Stream_Io;
with Text_Io;
procedure Ia_Problem is
type My_Type is mod 2**16;
for My_Type'Size use 16;
type My_Int is range - 2**15 ..
(2**15) - 1;
for My_Int'Size use 16;

type My_Uint is range 0 .. 65535;
for My_Uint'Size use 16;

A : My_Type := 5;
B : My_Int := 10;
C : My_Uint := 100;
File : Ada.Streams.Stream_Io.File_Type;
begin
Ada.Streams.Stream_Io.Create(
File => File,
Name => "show.bin");
My_Type'Write(Ada.Streams.Stream_Io.Stream(File),A); -- writes 16 bits
My_Int'Write(Ada.Streams.Stream_Io.Stream(File),B); -- writes 16 bits
My_Uint'Write(Ada.Streams.Stream_Io.Stream(File),C); -- writes 32 bits?
Text_Io.Put_Line(Integer'Image(C'Size));
Ada.Streams.Stream_Io.Close(File);
end Ia_Problem;



The 'write on my_uint writes 32 bits not 16 bits. I realize that the 'write
and 'size is an area where non-language
lawyers get into trouble all the time but it sure seems to me as if GNAT is
not following the IA.

What do others think?

(Note : CC'd to report@gnat.com)






^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GNAT bug with respect to an Implementation Advise
  2000-12-13 15:53 GNAT bug with respect to an Implementation Advise Jeff Creem
@ 2000-12-13 19:56 ` Florian Weimer
  2000-12-14  0:49   ` Randy Brukardt
  2000-12-14  1:40 ` Robert Dewar
  1 sibling, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2000-12-13 19:56 UTC (permalink / raw)


"Jeff Creem" <jeff@thecreems.com> writes:

> The LRM has an implementation advice that says:
> 
> 13.13.2(17): Stream Oriented Attributes
> 
> If a stream element is the same size as a storage element, then the normal
> in-memory representation should be used by Read and Write for scalar
> objects. Otherwise, Read and Write should use the smallest number of stream
> elements needed to represent all values in the base range of the scalar
                                                 ^^^^^^^^^^
> type.

'base range' is crucial here.

> To which the GNAT RM says
> 
> Followed.

Correct.

> type My_Uint is range 0 .. 65535;
> for My_Uint'Size use 16;

My_Uint'Base'First is -2**31, and My_Uint'Base'Last is 2**31-1, I
think.

> The 'write on my_uint writes 32 bits not 16 bits. I realize that the
> 'write and 'size is an area where non-language lawyers get into
> trouble all the time but it sure seems to me as if GNAT is not
> following the IA.

GNAT is following the IA, but the IA is surprising.  There's also an
AI on this issue, which involved a lot of discussion.  (Some vendors
do not follow the IA and want to change the standard to officially
sanction the derivation, IMHO.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GNAT bug with respect to an Implementation Advise
  2000-12-13 19:56 ` Florian Weimer
@ 2000-12-14  0:49   ` Randy Brukardt
  0 siblings, 0 replies; 7+ messages in thread
From: Randy Brukardt @ 2000-12-14  0:49 UTC (permalink / raw)


Florian Weimer wrote in message <87aea0xfgk.fsf@deneb.enyo.de>...

>GNAT is following the IA, but the IA is surprising.  There's also an
>AI on this issue, which involved a lot of discussion.  (Some vendors
>do not follow the IA and want to change the standard to officially
>sanction the derivation, IMHO.

No, that's an oversimplification. The problem is that the Ada 95
standard never specifies what the base range is. That is left up to
compilers. Thus, there is no way to tell how many bytes are written out
by a particular type. (There is also the issue that you can't read
hetrogenus data structures defined outside of Ada at all without some
control over this.)

For instance, if you have the type:
    type Byte is range 0 .. 255;
    for Byte'Size is 8;

the base range might be:
    Byte'Base'First = -32768, Byte'Base'Last = 32767 (i.e. 16 bits
read/written by streams)
or it might be
    Byte'Base'First = -2**31, Byte'Base'Last = 2**31-1 (i.e. 32 bits
read/written by streams)
or something else again (say on a 24-bit machine).

These are all legal, correct implementations of Ada, and even if all of
the implementations follow the IA, they won't be compatible.

                Randy.






^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GNAT bug with respect to an Implementation Advise
  2000-12-13 15:53 GNAT bug with respect to an Implementation Advise Jeff Creem
  2000-12-13 19:56 ` Florian Weimer
@ 2000-12-14  1:40 ` Robert Dewar
  2000-12-14  2:40   ` Jeff Creem
  1 sibling, 1 reply; 7+ messages in thread
From: Robert Dewar @ 2000-12-14  1:40 UTC (permalink / raw)


In article <t3f6rg54jlkfee@corp.supernews.com>,
  "Jeff Creem" <jeff@thecreems.com> wrote:
> The LRM has an implementation advice that says:
>
> 13.13.2(17): Stream Oriented Attributes


The RM is actually a little unclear here, since it
is not clear how subtypes should be treated when they

have different in memory sizes from the base type.

For example, suppose we write:

   type x is range 1 .. 1000;
   for x'size use 16;
   subtype y is x range 1 .. 10;
   xx : x;
   yy : y;

Now we can imagine several implementations, all valid
from the RM:

1. xx, yy both take 32 bits in memory
2. xx, yy both take 16 bits
3. xx takes 16 bits, yy takes 8 bits

Now you can imagine these three implementations
trying to follow the RM generating three different
streams, which seems unfortunately unportable, given
that the IA is presumably trying to create
uniformity.

What we did in GNAT was to decide that "normal in
memory representation" meant the space that the base
type would take, regardless of the space actually
occupied by individual subtype variables. But at
least one other implementation took approach 3.

So the RM is not the issue here, both these
implementations are following a reasonable
interpretation of the RM requirement.

What's wrong is the RM requirement!

What the AI did here was to normalize the stream
requirement to be the space that *would* be minimally
required to store the first subtype. Note that in
some implementations this might well not correspond
to ANY actual stored variable, and thus the AI
requirement might actually clearly violate the IA.

Nevertheless this seemed a reasonable way of making
things compatible, and we will introduce an option in
GNAT to conform to the AI (it has to be an option,
because otherwise we have a nasty incompatibility
with the previous valid implementation). Of course if
you do not use a size clause, the GNAT implementation
is conforming to the IA (whereas the approach of
different sizes for different subtypes is always
"wrong").

Robert Dewar


Sent via Deja.com
http://www.deja.com/



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GNAT bug with respect to an Implementation Advise
  2000-12-14  1:40 ` Robert Dewar
@ 2000-12-14  2:40   ` Jeff Creem
  2000-12-14 22:47     ` Randy Brukardt
  0 siblings, 1 reply; 7+ messages in thread
From: Jeff Creem @ 2000-12-14  2:40 UTC (permalink / raw)


Thanks everyone for the responses. I was hoping that I was missing something
obvious and it appears
that it was less than clear.

A while back I had found a site (I think at ada IC) that listed the latest
IA's..Sounds like I should
spend some time reading what is there.






^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GNAT bug with respect to an Implementation Advise
  2000-12-14  2:40   ` Jeff Creem
@ 2000-12-14 22:47     ` Randy Brukardt
  2000-12-15 22:00       ` Randy Brukardt
  0 siblings, 1 reply; 7+ messages in thread
From: Randy Brukardt @ 2000-12-14 22:47 UTC (permalink / raw)


>A while back I had found a site (I think at ada IC) that listed the
latest
>IA's..Sounds like I should
>spend some time reading what is there.

The AdaIC set is out of date and probably will be deleted in the next
purge. The home of the AIs is
    www.ada-auth.org/~acats/arg.html

            Randy Brukardt
            ARG Editor







^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GNAT bug with respect to an Implementation Advise
  2000-12-14 22:47     ` Randy Brukardt
@ 2000-12-15 22:00       ` Randy Brukardt
  0 siblings, 0 replies; 7+ messages in thread
From: Randy Brukardt @ 2000-12-15 22:00 UTC (permalink / raw)


Randy Brukardt wrote in message ...
>>A while back I had found a site (I think at ada IC) that listed the
latest
>>IA's..Sounds like I should spend some time reading what is there.
>
>The AdaIC set is out of date and probably will be deleted in the next
>purge. The home of the AIs is
>    www.ada-auth.org/~acats/arg.html

Let me try this again; despite checking the link and looking at it while
I typed, I *still* typed it wrong. Arggh! The correct link is:

    www.ada-auth.org/~acats/ais.html

           Randy Brukardt
           ARG Editor






^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2000-12-15 22:00 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-12-13 15:53 GNAT bug with respect to an Implementation Advise Jeff Creem
2000-12-13 19:56 ` Florian Weimer
2000-12-14  0:49   ` Randy Brukardt
2000-12-14  1:40 ` Robert Dewar
2000-12-14  2:40   ` Jeff Creem
2000-12-14 22:47     ` Randy Brukardt
2000-12-15 22:00       ` Randy Brukardt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox