* Streams and abnormality @ 2012-06-12 9:31 Simon Wright 2012-06-12 15:01 ` Adam Beneschan 0 siblings, 1 reply; 7+ messages in thread From: Simon Wright @ 2012-06-12 9:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Streams and abnormality 2012-06-12 9:31 Streams and abnormality Simon Wright @ 2012-06-12 15:01 ` Adam Beneschan 2012-06-12 17:03 ` Dmitry A. Kazakov 2012-06-12 17:32 ` Simon Wright 0 siblings, 2 replies; 7+ messages in thread From: Adam Beneschan @ 2012-06-12 15:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Streams and abnormality 2012-06-12 15:01 ` Adam Beneschan @ 2012-06-12 17:03 ` Dmitry A. Kazakov 2012-06-12 17:32 ` Simon Wright 1 sibling, 0 replies; 7+ messages in thread From: Dmitry A. Kazakov @ 2012-06-12 17:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Streams and abnormality 2012-06-12 15:01 ` Adam Beneschan 2012-06-12 17:03 ` Dmitry A. Kazakov @ 2012-06-12 17:32 ` Simon Wright 2012-06-12 18:06 ` Adam Beneschan 1 sibling, 1 reply; 7+ messages in thread From: Simon Wright @ 2012-06-12 17:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Streams and abnormality 2012-06-12 17:32 ` Simon Wright @ 2012-06-12 18:06 ` Adam Beneschan 2012-06-12 19:49 ` Simon Wright 2012-06-21 18:29 ` Randy Brukardt 0 siblings, 2 replies; 7+ messages in thread From: Adam Beneschan @ 2012-06-12 18:06 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Streams and abnormality 2012-06-12 18:06 ` Adam Beneschan @ 2012-06-12 19:49 ` Simon Wright 2012-06-21 18:29 ` Randy Brukardt 1 sibling, 0 replies; 7+ messages in thread From: Simon Wright @ 2012-06-12 19:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Streams and abnormality 2012-06-12 18:06 ` Adam Beneschan 2012-06-12 19:49 ` Simon Wright @ 2012-06-21 18:29 ` Randy Brukardt 1 sibling, 0 replies; 7+ messages in thread From: Randy Brukardt @ 2012-06-21 18:29 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-06-21 18:29 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-06-12 9:31 Streams and abnormality Simon Wright 2012-06-12 15:01 ` Adam Beneschan 2012-06-12 17:03 ` Dmitry A. Kazakov 2012-06-12 17:32 ` Simon Wright 2012-06-12 18:06 ` Adam Beneschan 2012-06-12 19:49 ` Simon Wright 2012-06-21 18:29 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox