CVS difference for ais/ai-00149.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00149.txt

--- ais/ai-00149.txt	1998/09/30 00:17:27	1.1
+++ ais/ai-00149.txt	2000/05/17 20:49:06	1.2
@@ -1,23 +1,23 @@
-!standard 08.06    (12)                               97-08-19  AI95-00149/02
+!standard 08.06    (12)                               00-05-11  AI95-00149/03
 !class confirmation 96-09-04
 !status received 96-09-04
 !priority Low
 !difficulty Easy
 !subject Miscellaneous Confirmations
 
-!summary 96-09-05
+!summary
 
 This AI includes a random assortment of questions that seem to have been
 answered satisfactorily via e-mail.  The intent is that the ARG will not
 consider this AI in the forseeable future.
 
-!question 96-09-04
+!question
 
 
-!response 96-09-04
+!response
 
 
-!appendix 97-08-19
+!appendix
 
 !section 8.6(12)
 !subject Are formal parameter names used in overload resolution ?
@@ -263,7 +263,7 @@
 X OR MORE units or raise Storage_Error.  The attribute must return X  OR MORE.
 
 An implementation is also allowed to have storage associated with a task
-object which is NOT counted in the attribute's measurement.  
+object which is NOT counted in the attribute's measurement.
 
 I have some difficulties with the RM in these paragraphs:
 
@@ -285,7 +285,7 @@
    Y units of storage such that X < Y < unknown.  And the value of
    'Storage_Size will be Z such that X < Z < unknown.  Y may be greater than,
    less than, or equal to Z.  The system may actually consume an amount of
-   space greater than Y or Z.  
+   space greater than Y or Z.
 
 ---------------------------------------------------------------------------
 W. Wesley Groleau (Wes)                                Office: 219-429-4923
@@ -308,12 +308,12 @@
 
 > when you give pragma storage_size (X), the implementation must reserve
 > X OR MORE units or raise Storage_Error.  The attribute must return X  OR MORE.
-> 
+>
 > An implementation is also allowed to have storage associated with a task
-> object which is NOT counted in the attribute's measurement.  
-> 
+> object which is NOT counted in the attribute's measurement.
+>
 > I have some difficulties with the RM in these paragraphs:
-> 
+>
 > 1. RM says that the units are "storage elements" but the Annotated RM,
 >    hints in 13.3(66.a) that it's "bytes"  Now the definition of "byte" has
 >    been debated at length within the last six months, but I don't think the
@@ -352,12 +352,12 @@
 
 > To put it another way, the following BOGUS interpretation does not
 > violate the RM:
-> 
+>
 >    If you give a task "pragma Storage_Size(X);" then the system will reserve
 >    Y units of storage such that X < Y < unknown.  And the value of
 >    'Storage_Size will be Z such that X < Z < unknown.  Y may be greater than,
 >    less than, or equal to Z.  The system may actually consume an amount of
->    space greater than Y or Z.  
+>    space greater than Y or Z.
 
 Yes.  But suppose the RM said that *exactly* X storage elements are
 reserved, and that 'Storage_Size returns *exactly* X.  Would that be any
@@ -409,7 +409,7 @@
 the identity Enum'Value(Enum'Image(E)) = E is not required to hold, even
 if no exception is raised.
 
--- 
+--
 Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
 TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
@@ -434,14 +434,14 @@
 > of the Wide_Image and Wide_Value attributes are implementation defined.
 > The Image, Value, and Wide_Width, and Width attributes are still defined
 > in terms of Wide_Image and Wide_Value.
-> 
+>
 > How much latitude do implementations have in this area?  May Enum'Image,
 > for example, raise an exception?  If it does, the definition of Enum'Width
 > becomes ambiguous; does it also raise an exception?
-> 
+>
 > May Enum'Image be rejected at compile time, i.e., does illegality fall
 > within the meaning of "semantics"?
-> 
+>
 > I presume it's legal to Enum'Image to fail (in some manner) for non-static
 > arguments but to succeed for static arguments, or more generally, for
 > arguments that can be evaluated at compilation time.  I also presume that
@@ -571,9 +571,9 @@
 > NOT "integer literal" (and not "numeric_literal", either); in this, it's
 > consistent with Ada83.
 
-I stand corrected.  I had failed to see the significance of "numeric literal  
-without a point" as opposed to "integer literal".  Although "an integer  
-literal is a numeric literal without a point" (RM95 2.4(1)), a numeric literal  
+I stand corrected.  I had failed to see the significance of "numeric literal
+without a point" as opposed to "integer literal".  Although "an integer
+literal is a numeric literal without a point" (RM95 2.4(1)), a numeric literal
 without a point is _not_ an integer literal.  Silly me! :-)
 
 To Bob Duff: this should go to the "stupid questions" AI.
@@ -623,7 +623,7 @@
 
 Regards,
 
--- 
+--
 Alain Le Guennec
 
 ****************************************************************
@@ -637,7 +637,7 @@
 !discussion
 
 > Please consider the following example:
-> 
+>
 >    procedure Example is
 >    begin
 >       <<Label1>>
@@ -645,7 +645,7 @@
 >       <<Label2>>
 >       null;
 >    end Example;
-> 
+>
 > The question is:
 > Is <<Label2>> legal here ?
 
@@ -653,21 +653,21 @@
 
 > According to 2.8(7), a pragma can be put where a syntactic category
 > ending by "statement" can (but not in place of such a construct).
-> 
+>
 > The example above corresponds to:
 >   the_example_statement ::= label pragma label simple_statement
-> 
+>
 > which I can't obtain starting with 5.1(3)
 >   statement ::= {label} simple_statement | {label} compound_statement
 > and then inserting "pragma" where it is allowed to do so.
-> 
+>
 > The closest I can get with those rules is first:
 >   statement ::= label label simple_statement
 > then:
 >   statement ::= label label pragma simple_statement
 > but pragma can't seem to be inserted after the first label,
 > because of the second one.
-> 
+>
 > I ask this because the GNAT compiler does not complain on this example,
 > and I'd like to know whether it should or not.
 
@@ -684,11 +684,11 @@
 !discussion
 
    An issue has been raised here at Concurrent regarding the designated
-   subtype of a derived access type.  
+   subtype of a derived access type.
 
    For a particular example, consider test c34007f.ada in the 9xbasic
    portion of the ACVC 2.0.1 suite.  At line 130, constraint_error is
-   expected.  It is not clear to me why, in light of sliding permitted by 
+   expected.  It is not clear to me why, in light of sliding permitted by
    Ada95, unless I'm determining the designated subtype of T incorrectly.
 
    Consider these relevant declarations from the test:
@@ -717,7 +717,7 @@
 
    The crux of the confusion seems to be the definition of the designated
    subtype involved.  Since T is a derived type, it isn't clear to me whether
-   the designated subtype of T is 
+   the designated subtype of T is
 
          DESIGNATED (IDENT_INT (5) .. IDENT_INT (7))
 
@@ -737,11 +737,11 @@
    subtype of a derived type (derived from an access type), and the test
    expects behavior implying the unconstrained designated type, I must
    assume that the designated subtype of the derived type is the
-   (unconstrained) designated subtype of the parent type, "DESIGNATED". 
+   (unconstrained) designated subtype of the parent type, "DESIGNATED".
    Is this the case?
 
-   It's a bit strange that the designated type would not be constrained by 
-   the constraint applied to the derived type declaration, since the 
+   It's a bit strange that the designated type would not be constrained by
+   the constraint applied to the derived type declaration, since the
    constraint would apply if it were a normal access type definition.
    On the other hand, T is NOT defined by an access_to_object_definition,
    or an access_definition, so RM95 3.10(16) doesn't apply to T, does it?
@@ -754,7 +754,7 @@
    Lead Software Engineer
    Concurrent Computer Corporation
 
--- 
+--
   Dan.Rittersdorf@mail.ccur.com        or              RittersdorfD@ACM.org
 ______________________________________________________________________________
   Concurrent Computer Corporation      |               Daniel G. Rittersdorf
@@ -777,49 +777,49 @@
 !discussion
 
 >    An issue has been raised here at Concurrent regarding the designated
->    subtype of a derived access type.  
-> 
+>    subtype of a derived access type.
+>
 >    For a particular example, consider test c34007f.ada in the 9xbasic
 >    portion of the ACVC 2.0.1 suite.  At line 130, constraint_error is
->    expected.  It is not clear to me why, in light of sliding permitted by 
+>    expected.  It is not clear to me why, in light of sliding permitted by
 >    Ada95, unless I'm determining the designated subtype of T incorrectly.
-> 
+>
 >    Consider these relevant declarations from the test:
-> 
-> 
+>
+>
 >            SUBTYPE COMPONENT IS INTEGER;
-> 
+>
 >            TYPE DESIGNATED IS ARRAY (NATURAL RANGE <>) OF COMPONENT;
-> 
+>
 >            PACKAGE PKG IS
-> 
+>
 >                 TYPE PARENT IS ACCESS DESIGNATED;
-> 
+>
 >            END PKG;
 >            USE PKG;
-> 
+>
 >            TYPE T IS NEW PARENT (IDENT_INT (5) .. IDENT_INT (7));
-> 
+>
 >            X : T := ... ;
-> 
+>
 >            ...
-> 
+>
 >            X := NEW DESIGNATED'(6 .. 8 => 0);
-> 
-> 
+>
+>
 >    This assignment statement is expected to raise constraint_error, but
 >    if I determined the designated subtype correctly, it should not.
-> 
+>
 >    The crux of the confusion seems to be the definition of the designated
 >    subtype involved.  Since T is a derived type, it isn't clear to me whether
->    the designated subtype of T is 
-> 
+>    the designated subtype of T is
+>
 >          DESIGNATED (IDENT_INT (5) .. IDENT_INT (7))
-> 
+>
 >    applying the constraint of the derived access type T, or just
-> 
+>
 >          DESIGNATED
-> 
+>
 >    because the derived type's constraint is not applied to the designated
 >    subtype, but rather it keeps the parent type's designated subtype.
 
@@ -829,13 +829,13 @@
 If the constraint is specified as part of the derived type definition,
 then it applies to all subtypes of that derived type.
 
-The constraint of an access subtype is irrelevant during evalution of 
+The constraint of an access subtype is irrelevant during evalution of
 the allocator, as that is only worried about the properties of the
 underlying type, and its designated subtype (which in this case is
 DESIGNATED, for PARENT any all of its derivatives).
 
 However, the constraint of T becomes relevant on the assignment to X.
-At that point, the designated object is checked to see whether it 
+At that point, the designated object is checked to see whether it
 satisfies the constraint of T.  No sliding applies to that check,
 since the object already exists in the heap with particular array bounds.
 
@@ -850,15 +850,15 @@
 >    subtype of a derived type (derived from an access type), and the test
 >    expects behavior implying the unconstrained designated type, I must
 >    assume that the designated subtype of the derived type is the
->    (unconstrained) designated subtype of the parent type, "DESIGNATED". 
+>    (unconstrained) designated subtype of the parent type, "DESIGNATED".
 >    Is this the case?
 
 Yes.  The designated subtype is a property of the type, and is inherited
 as is by derived types.  An analogy would be the subtype of a component
-of a record.  It is inherited as is by all derivatives.  
+of a record.  It is inherited as is by all derivatives.
 
->    It's a bit strange that the designated type would not be constrained by 
->    the constraint applied to the derived type declaration, since the 
+>    It's a bit strange that the designated type would not be constrained by
+>    the constraint applied to the derived type declaration, since the
 >    constraint would apply if it were a normal access type definition.
 
 A constraint that appears in an access type definition is very different
@@ -879,17 +879,50 @@
 
 >    On the other hand, T is NOT defined by an access_to_object_definition,
 >    or an access_definition, so RM95 3.10(16) doesn't apply to T, does it?
-> 
+>
 >    Your comments on the matter would be much appreciated.
 
 See above.
 
 >    Thank you,
-> 
+>
 >    Daniel G. Rittersdorf
 >    Lead Software Engineer
 >    Concurrent Computer Corporation
 
 -Tucker Taft  stt@inmet.com
+
+****************************************************************
+
+From: Christoph Grein
+Sent: Thursday, May 11, 2000 12:00 AM
+
+!topic Definition of Space
+!reference RM95-A.4.1(4), RM95-A.3.3(8,21)
+!from Christoph Grein 2000-05-11
+!keywords haracter, space
+!discussion
+
+In package Ada.Strings, the object Space is defined as
+
+  Space: constant Character := ' ';
+
+While everybody should interprete this in the correct way, is it from a formal
+point of view correctly defined?
+
+See package Ada.Characters.Latin_1, where the same literal ' ' is used twice
+for different objects, namely Space and No_Break_Space. Here it is made clear
+in a comment which object is meant.
+
+So is A.4.1(4) Space formally defined as Character'Val(32) or as
+Character'Val(160)?
+
+****************************************************************
+
+From: Michael Yoder
+Sent: Thursday, May 11, 2000 11:44 AM
+
+The answer is at A.1(49), after the definition of Standard; this also
+answers the question for hyphen and soft hyphen.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent