Streams and abnormality

Streams and abnormality

[Simon Wright]

Using this code with GCC 4.6, 4.7 and GNAT GPL 2011,

      Str : aliased {a child of Root_Stream_Type};
      subtype Short_Int is Integer range 0 .. 42;
      S : Short_Int;
   begin
      Integer'Output (Str'Access, -1);
      S := Short_Int'Input (Str'Access);
      Put_Line (S'Img & " " & S'Valid'Img);

I get the output " 63 FALSE".

 My reading of AARM05 13.9.1(4..6) [1] is that - because S is a scalar
 object - S should not have been allowed to become abnormal; I think
 that, instead, some exception (Constraint_Error? Data_Error?) should
 have been raised.

[1] http://www.adaic.org/resources/add_content/standards/05aarm/html/AA-13-9-1.html

Re: Streams and abnormality

[Adam Beneschan]

On Tuesday, June 12, 2012 2:31:17 AM UTC-7, Simon Wright wrote:
> Using this code with GCC 4.6, 4.7 and GNAT GPL 2011,
> 
>       Str : aliased {a child of Root_Stream_Type};
>       subtype Short_Int is Integer range 0 .. 42;
>       S : Short_Int;
>    begin
>       Integer'Output (Str'Access, -1);
>       S := Short_Int'Input (Str'Access);
>       Put_Line (S'Img & " " & S'Valid'Img);
> 
> I get the output " 63 FALSE".
> 
>  My reading of AARM05 13.9.1(4..6) [1] is that - because S is a scalar
>  object - S should not have been allowed to become abnormal; I think
>  that, instead, some exception (Constraint_Error? Data_Error?) should
>  have been raised.
> 
> [1] http://www.adaic.org/resources/add_content/standards/05aarm/html/AA-13-9-1.html

You're right; it should have raised Constraint_Error, but I think it has nothing to do with 13.9.1, because Short_Int'Input is defined to return a value of type Short_Int'Base, not Short_Int (13.13.2(23), which actually says Short_Int'Input returns the *type* T of which Short_Int is a subtype, but I think that's the same thing).  Thus, in a normal situation, the result of Short_Int'Input *cannot* be an invalid value, because (if Integer'Size = 16) then 16 bits will be read from the stream, and all possible 16-bit bit patterns are valid values of Short_Int'Base.  I don't see anything in 13.13.2 that says the function result of ST'Input is checked against the constraints defined for subtype ST.  The Constraint_Error should occur during the assignment, when the value of the expression (of type S'Base) needs to be constraint-checked before assigning into S, just as it would if *any* function returning Integer appeared on the right side of the assignment. 

After rereading 13.9.1, though, I think it's wrong to suppose that there's a dichotomy between "abnormal" and "must raise an exception".  13.9.1 appears to define two different concepts, abnormal objects and objects with invalid representation.  A scalar object can have invalid representation without being abnormal, and this condition could be produced by stream operations, such as T'Input where T is an enumeration type.  It looks like the main difference between "abnormal objects" and "scalars with invalid representation" is that the latter is a "bounded error" and there is more definition about what programs are required to do with scalars to ensure they don't make a huge mess.  But raising an exception isn't required.

                               -- Adam

Re: Streams and abnormality

[Dmitry A. Kazakov]

On Tue, 12 Jun 2012 08:01:03 -0700 (PDT), Adam Beneschan wrote:

[...]

Thank you for clarification.

Yet another reason for my rule of thumb: always override stream I/O
attributes.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Streams and abnormality

[Simon Wright]

Adam Beneschan <adam@irvine.com> writes:

> On Tuesday, June 12, 2012 2:31:17 AM UTC-7, Simon Wright wrote:
>> Using this code with GCC 4.6, 4.7 and GNAT GPL 2011,
>> 
>>       Str : aliased {a child of Root_Stream_Type};
>>       subtype Short_Int is Integer range 0 .. 42;
>>       S : Short_Int;
>>    begin
>>       Integer'Output (Str'Access, -1);
>>       S := Short_Int'Input (Str'Access);
>>       Put_Line (S'Img & " " & S'Valid'Img);
>> 
>> I get the output " 63 FALSE".
>> 
>>  My reading of AARM05 13.9.1(4..6) [1] is that - because S is a scalar
>>  object - S should not have been allowed to become abnormal; I think
>>  that, instead, some exception (Constraint_Error? Data_Error?) should
>>  have been raised.
>> 
>> [1] http://www.adaic.org/resources/add_content/standards/05aarm/html/AA-13-9-1.html
>
> You're right; it should have raised Constraint_Error, but I think it
> has nothing to do with 13.9.1, because Short_Int'Input is defined to
> return a value of type Short_Int'Base, not Short_Int (13.13.2(23),
> which actually says Short_Int'Input returns the *type* T of which
> Short_Int is a subtype, but I think that's the same thing).  Thus, in
> a normal situation, the result of Short_Int'Input *cannot* be an
> invalid value, because (if Integer'Size = 16) then 16 bits will be
> read from the stream, and all possible 16-bit bit patterns are valid
> values of Short_Int'Base.  I don't see anything in 13.13.2 that says
> the function result of ST'Input is checked against the constraints
> defined for subtype ST.  The Constraint_Error should occur during the
> assignment, when the value of the expression (of type S'Base) needs to
> be constraint-checked before assigning into S, just as it would if
> *any* function returning Integer appeared on the right side of the
> assignment.
>
> After rereading 13.9.1, though, I think it's wrong to suppose that
> there's a dichotomy between "abnormal" and "must raise an exception".
> 13.9.1 appears to define two different concepts, abnormal objects and
> objects with invalid representation.  A scalar object can have invalid
> representation without being abnormal, and this condition could be
> produced by stream operations, such as T'Input where T is an
> enumeration type.  It looks like the main difference between "abnormal
> objects" and "scalars with invalid representation" is that the latter
> is a "bounded error" and there is more definition about what programs
> are required to do with scalars to ensure they don't make a huge mess.
> But raising an exception isn't required.

Thanks, Dennis & Adam.

I think Dennis is right; there's no explicit statement of what checks
are made for a bare scalar, but AARM05 13.13.2(35)[1] says that scalar
*components* are only checked if they are discriminants or if the
component_declaration has a default_expression.

Looking at the AI[2], I must say I don't see quite where the
"discriminants or if the component_declaration has a default_expression"
comes from. It looks to me as though this should have read
"discriminants whose component_declaration has a default_expression"
(see !summary 7).

With GNAT, -gnatVc (turn on validity checking for copies) catches the
problem in my code.

[1] http://www.adaic.org/resources/add_content/standards/05aarm/html/AA-13-13-2.html
[2] http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00195.txt?rev=1.33

Re: Streams and abnormality

[Adam Beneschan]

On Tuesday, June 12, 2012 10:32:00 AM UTC-7, Simon Wright wrote:

 
> Looking at the AI[2], I must say I don't see quite where the
> "discriminants or if the component_declaration has a default_expression"
> comes from. 

Well, the wording was there in the first version of Ada 95 (AI95-195 didn't change it).  !summary 7 has to do with discriminants that don't match when 'Read is called, the discriminants have default expressions (otherwise they're not read from the stream), and the actual parameter is constrained.  It doesn't address the issue of invalid representations.

In RM12, the wording will be changed to "for each scalar component that is a discriminant or that has an implicit initial value".  But I think this indicates that the wording was deliberate.  I don't know why it was important to specify this for components with default expressions (or implicit initial values), and the Ada 95 Rationale doesn't say.  Anyway, your thinking that maybe they meant that it applies only to discriminants with default expressions, doesn't make sense; it has to apply to all discriminants, because the discriminant could be used to control a variant part, and reading a discriminant with an invalid value is going to wreak havoc regardless of whether it has a default expression.

                         -- Adam


> It looks to me as though this should have read
> "discriminants whose component_declaration has a default_expression"
> (see !summary 7).

Re: Streams and abnormality

[Simon Wright]

Adam Beneschan <adam@irvine.com> writes:

> On Tuesday, June 12, 2012 10:32:00 AM UTC-7, Simon Wright wrote:
>
>  
>> Looking at the AI[2], I must say I don't see quite where the
>> "discriminants or if the component_declaration has a default_expression"
>> comes from. 
>
> Well, the wording was there in the first version of Ada 95 (AI95-195
> didn't change it).  !summary 7 has to do with discriminants that don't
> match when 'Read is called, the discriminants have default expressions
> (otherwise they're not read from the stream), and the actual parameter
> is constrained.  It doesn't address the issue of invalid
> representations.
>
> In RM12, the wording will be changed to "for each scalar component
> that is a discriminant or that has an implicit initial value".  But I
> think this indicates that the wording was deliberate.  I don't know
> why it was important to specify this for components with default
> expressions (or implicit initial values), and the Ada 95 Rationale
> doesn't say.  Anyway, your thinking that maybe they meant that it
> applies only to discriminants with default expressions, doesn't make
> sense; it has to apply to all discriminants, because the discriminant
> could be used to control a variant part, and reading a discriminant
> with an invalid value is going to wreak havoc regardless of whether it
> has a default expression.
>
>                          -- Adam
>
>> It looks to me as though this should have read "discriminants whose
>> component_declaration has a default_expression" (see !summary 7).

Yes, I see. But nevertheless it seems that maybe the result of 'Input
(or 'Read) needn't be checked in the case of a bare scalar.

Would it be actually wrong for a compiler to check (in its default
mode)? Looks like it ("For other components, no check is made.").

Anyway, I'm writing an Ada implementation of Message_Pack[1]; since I'm
not re-implementing 'Read or 'Input, I have to check values read from
the stream.

A Message_Pack stream contains items, where an item consists of an
item-type byte followed, possibly, by more data; for example, 8388608
(2**23) would be {0xd2, 0x0, 0x80, 0x0, 0x0} ("int32" type byte, 4 bytes
of big-endian data).

Considering the (generic) code to read an integer type (range <>), I was
thinking that if the item-type byte doesn't correspond to an integer
value - for example, it might be 0xc2, false - I would raise Data_Error,
whereas if the integral value read wouldn't match the required
constraints I'd raise Constraint_Error. Does that seem reasonable?

[1] http://msgpack.org

Re: Streams and abnormality

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:b05bd568-3d76-4816-ad25-95bb8175b802@googlegroups.com...
On Tuesday, June 12, 2012 10:32:00 AM UTC-7, Simon Wright wrote:

>> Looking at the AI[2], I must say I don't see quite where the
>> "discriminants or if the component_declaration has a default_expression"
>> comes from.
>
>Well, the wording was there in the first version of Ada 95 (AI95-195 didn't 
>change it).
>!summary 7 has to do with discriminants that don't match when 'Read is 
>called, the
>discriminants have default expressions (otherwise they're not read from the 
>stream),
>and the actual parameter is constrained.  It doesn't address the issue of 
>invalid representations.

>In RM12, the wording will be changed to "for each scalar component that is 
>a discriminant or
>that has an implicit initial value".  But I think this indicates that the 
>wording was deliberate.
>I don't know why it was important to specify this for components with 
>default expressions (or
>implicit initial values), and the Ada 95 Rationale doesn't say.

The idea (I think) is that components with valid initial values can't get 
"deinitialized" by streaming in garbage. But if they're not initialized, 
then its OK for them to have garbage (since they start out that way anyway). 
There is a similar rule for "out" parameters - for Ada 2012, we had to 
include values that are initialized via a "Default_Value" aspect (which is 
why the wording changes).

                                                  Randy.