From owner-sc22docs@open-std.org Tue Jul 18 16:13:04 2006 Return-Path: X-Original-To: sc22docs-domo3 Delivered-To: sc22docs-domo3@open-std.org Received: by open-std.org (Postfix, from userid 521) id 1210A152CA; Tue, 18 Jul 2006 16:13:03 +0200 (CET DST) X-Original-To: sc22info@open-std.org Delivered-To: sc22docs@open-std.org Received: from 0e0mail1.ansi.org (outbound.ansi.org [12.15.192.5]) by open-std.org (Postfix) with ESMTP id 150021212B for ; Tue, 18 Jul 2006 16:12:57 +0200 (CET DST) Received: by EMAIL1 with Internet Mail Service (5.5.2653.19) id <33SNSWFQ>; Tue, 18 Jul 2006 10:09:36 -0400 Message-ID: From: Sally Seitz To: sc22info@open-std.org Subject: N 4082-Defect Report 2 for ISO/IEC 1539-1: 2004, Programming lang uages - Fortran Date: Tue, 18 Jul 2006 10:09:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AA73.CC113FA2" Sender: owner-sc22docs@open-std.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C6AA73.CC113FA2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ISO/IEC JTC 1/SC22 Programming languages, their environments and system software = interfaces Secretariat:=A0 U.S.A.=A0 (ANSI)=20 =A0=20 ISO/IEC JTC 1/SC22 N4082 =A0=20 TITLE:=20 Defect Report 2 for ISO/IEC 1539-1: 2004, Programming languages - = Fortran DATE ASSIGNED:=20 2006-07-17 =A0=20 SOURCE:=20 SC 22/WG 5 Convener (J. Reid) BACKWARD POINTER:=20 N/A=20 =A0=20 DOCUMENT TYPE:=20 Defect Report =A0 PROJECT NUMBER:=20 =A0=20 STATUS:=20 For information and review when voting on N 4080. ACTION IDENTIFIER:=20 FYI =A0=20 DUE DATE:=20 =A0=20 DISTRIBUTION:=20 TEXT CROSS REFERENCE:=20 =A0=20 DISTRIBUTION FORM:=20 Def=20 _________end of cover sheet, beginning of document___________ ISO/IEC JTC1/SC22/WG5 N1666 Defect Report 2 for Fortran 2003 All edits specified in this document relate to WG5-N1601 (j3/04-007). Other references to page and line numbers in general refer to the standard document as it was at the time of the initial interpretation request and/or subsequent interpretation work. ---------------------------------------------------------------------- =20 NUMBER: F03/0008 TITLE: Pointer assignment and arrays KEYWORDS: pointer assignment, array, data-ref DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: There appears to be no explicit requirement that the s in R736 and R741 be scalar. If data-pointer-object and proc-component ref were data-refs, then C614 would prohibit the s from being arrays. However, although the syntax looks like a special case of a data-ref, nothing appears to say that R736 and R741 actually constitute data-refs. The standard gives no interpretation as to what the meaning would be in the case of an array. Even when variable is a scalar, the standard does not appear to define what the properties (such as type and shape) of a data-pointer-object or proc-pointer-object are in the case where the syntax has a "%". All we have is a syntax with no established meaning. Q1. Is the in R736 or R741 allowed to be an array? Q2. Is the interpretation of the forms in R736 and R741 the same as that of a data-ref? ANSWER: A1. No. The standard provides no interpretation of what such a form would mean. Therefore, by the first sentence of 1.5, it is not standard-conforming. Edits are provided to make this prohibition more direct. A2. Yes. EDITS: All edits refer to 04-007. [143:12,24,35,37] Insert "" before "", four times. SUBMITTED BY: Richard Maine HISTORY: 04-333 m169 F03/0008 Submitted 04-333r1 m169 Passed by J3 meeting 04-418r1 m170 Failed J3 letter ballot #9 04-421 m170 Revised - Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0012 TITLE: Procedure pointers and the EXTERNAL attribute KEYWORDS: Procedure pointers, EXTERNAL DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Is the following program unit standard conforming? SUBROUTINE SUB ( RPP ) REAL, EXTERNAL, POINTER :: RPP EXTERNAL :: PP POINTER :: PP PROCEDURE(REAL), POINTER :: PPP =3D> NULL() END SUBROUTINE SUB The last sentence of "5.1.2.6 EXTERNAL attribute" appears to indicate that it is allowed: "A procedure that has both the EXTERNAL and POINTER attributes is a procedure pointer." That the title of subclause 12.2.1.2 is "Characteristics of dummy procedures and dummy procedure pointers" suggests that it is allowed. That subclause continues "... whether it is a pointer, ..." so it was clearly envisioned that at least dummy procedures could have the POINTER attribute. C1216 [264:30] appears to require PPP to be allowed: "C1216 (R1214) If =3D> appears in , the procedure entity shall have the pointer attribute." On the other hand, A conspiracy of C512 [72:28-29] "C512 (R501) If the POINTER attribute is specified, the ALLOCATABLE, TARGET, EXTERNAL, or INTRINSIC attribute shall not be specified." the second sentence of subclause 5.1.2.6 [80:38-40] "This [EXTERNAL] attribute may also be specified by ... a ..." the first paragraph of subclause 5.2 [85:15ff] "The combination of attributes that may be specified for a particular entity is subject to the same restrictions ... regardless of the method of specification. This also applies to the PROCEDURE, EXTERNAL and INTRINSIC statements." and the last sentence of the first paragraph of 12.3.2.3 [264:8] "It [the procedure declaration statement] specifies the EXTERNAL attribute...." appears to completely wipe out procedure pointers (PPP because of the first paragraph of 12.3.2.3). C521 [73:6-7] and C568 [91:5] also appear to prohibit RPP and PP: "C521 (R504) The shall be the name of an external function, a function dummy procedure{, or a statement function}." "C568 (R541) A shall also be declared in a ." But then the first paragraph after R1210 (defining the EXTERNAL statement) [264:1] appears to allow RPP and PP: "Each shall be the name of ... a procedure pointer...." There is also a problem with protected procedure pointers. C535 clearly envisions their existence: "C535 (R501) The PROTECTED attribute is permitted only for a procedure pointer...." while C536 prohibits their existence: "C536 (R501) If the PROTECTED attribute is specified, the EXTERNAL ... attribute shall not be specified." ANSWER: The discussion of procedure pointers is indeed inconsistent. The program unit is intended to be standard conforming. It was an oversight during the development of the procedure pointer facility that the EXTERNAL attribute was not removed from C512, that "procedure pointer" was not added to C521, that C535 and C536 contradict one another, and that an external statement and specifying the EXTERNAL attribute in a type declaration statement were not allowed in C568. It is not helpful that the last sentence of the first paragraph of subclause 5.2 refers to "PROCEDURE ... statements" (which could be confused with the PROCEDURE statement in an interface block) where it should refer to "procedure declaration ... statements." EDITS: Delete ", EXTERNAL" from C512 [72:28]. Insert ", a procedure pointer" after "dummy procedure" in C521 [73:7]. Replace C536 [73:35-36]: "C536 (R501) If the PROTECTED attribute is specified, the INTRINSIC or PARAMETER attribute shall not be specified. If the PROTECTED and EXTERNAL attributes are specified, the POINTER attribute shall also be specified." Replace the last sentence of the first paragraph of subclause 5.2 [86:1] by "This also applies to procedure declaration statements, and to EXTERNAL and INTRINSIC statements." Replace C568 [91:5]: "C568 (R541) The EXTERNAL attribute (5.1.2.6) shall be explicitly specified for a ." SUBMITTED BY: Van Snyder HISTORY: 04-358 m169 F03/0012 Submitted 04-358r2 m169 Revised 04-418r1 m170 Failed J3 letter ballot #9 04-401r2 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 - fix typo N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0020 TITLE: Kinds of intrinsic type parameters KEYWORDS: type parameter, kind, intrinsic type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Q1. What are the kinds of the type parameters for intrinsic types? In most contexts, it doesn't matter. Fortran 95 did not even have the concept of the kind of a type parameter or a context in which such a thing could be detected in a standard-conforming program. Fortran 2003 added the concept in support of derived types. It also added a syntax which exposes the question for intrinsic types. Q2. What is the KIND of a type parameter inquiry? Q3. For example, consider the program program what_kind character c write (*,*) kind(c%kind) =3D=3D kind(0) write (*,*) kind(c%len) =3D=3D kind(0) end Are both write statements guaranteed to print .true. (meaning that the c%kind and c%len are of default kind) or not? For KIND parameters, although I can't find it explicitly stated, I see fairly strong evidence that all intrinsic kind parameters are intended to be default integers. This evidence is in the intrinsic functions. The KIND intrinsic function and all the selected_*_kind functions are specified to return default integers, which would make for some strangeness if the kind parameters were not default integer, in particular if the KIND intrinsic could not return the kind of its argument because that kind could not be represented in a default integer. There also seems no obvious benefit to having the kind of the intrinsic kind parameters be anything other than default. In practice, the number of supported values for kind is small and would have no trouble being represented in a default integer; large arrays of kind values are rare, so there isn't much benefit in using representations smaller than default. For character length, I see no similar evidence. Indeed, the LEN intrinsic seems to suggest that lengths might be other than default integer. I believe that there was clear intent to facilitate (but not require) support for character lengths longer than could be expressed by a default integer. In most contexts, it doesn't directly matter what the kind of length is. Parameter specifications in type-specs don't have to match in kind. So the user could specify and do arithmetic on lengths using whatever kind was appropriate for the anticipated problem sizes. The limit on maximum character length is processor-dependent anyway and is not necessarily the same as HUGE(whatever) (though it is a bit hard to imagine how it could usefully be larger). The only context in which I can see that might matter is in a type parameter inquiry (6.1.3). We don't appear to have defined the kind of a type parameter inquiry. Although we didn't say, I am assuming that a type parameter inquiry ought to "return" the kind of the type parameter it is inquiring about. Otherwise, there would be no way to inquire about the type parameter values of some derived type variables (if the values didn't fit in a default integer). We probably ought to explicitly say, though. ANSWER: Q1. The kind parameters of all the intrinsic types are of default integer kind. The kind parameter of the intrinsic character length parameter is processor-dependent. The support for this answer is as described in the question. Edits are provided to make this answer explicit. Q2. The kind parameter of a type inquiry is the same as that of the type parameter inquired about. See page 123, lines 35-36. Q3. The first write statement is guaranteed to print a .true. value; it is processor dependent whether the second one prints a .true. or .false. value. EDITS: All edits apply to 04-007. At [36:14], [37:30], [39:15], [40:14], and [44:2], insert the following sentence before "The kind": The kind type parameter is of type default integer. At [40:10], before "its", insert "its kind is processor-dependent and". SUBMITTED BY: Richard Maine HISTORY: 04-408 m170 F03/0020 Submitted 04-408r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0023 TITLE: IEEE_SET/GET_UNDERFLOW_MODE KEYWORDS: IEEE, underflow mode DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Is it allowed for the argument of IEEE_SET_UNDERFLOW_MODE or IEEE_GET_UNDERFLOW_MODE to be an array? There appears to be no restriction against arrays in these procedures. For IEEE_SET_UNDERFLOW_MODE, it is ill-defined what an array would mean. The wording implies a scalar, in that it talks about being true or false, but the restriction to scalars is not explicit. For IEEE_GET_UNDERFLOW_MODE, it could be defined, but seems a little silly and nonparallel. The similar procedures for rounding mode do explicitly specify that their arguments are scalar. ANSWER: No, arrays are not allowed for these arguments. Edits are provided to correct this error. EDITS: [374:21] Add "scalar and" after "shall be" [380:13] Add "scalar and" after "shall be" SUBMITTED BY: Richard Maine HISTORY: 04-420 m170 F03/0023 Submitted - Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0025 TITLE: Abstract types in CLASS IS type guard statements KEYWORDS: ABSTRACT, CLASS IS, type guard, SELECT TYPE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: PROGRAM foo TYPE, ABSTRACT :: base INTEGER i END TYPE TYPE, EXTENDS(base) :: child INTEGER j END TYPE CLASS(*), POINTER :: x TYPE(child), TARGET :: c1 x =3D> c1 SELECT TYPE (x) CLASS IS (base) PRINT *, 'Class is base' CLASS DEFAULT PRINT *, 'Class is not base' END SELECT END Constraint C401 seems to prohibit the abstract type "base" from appearing in a CLASS IS type guard statement, thus prohibiting this program. There seems to be no reason to prohibit this, and allowing it seems to be useful in some situations. Was this program intended to be standard-conforming? ANSWER: Yes, this program was intended to be standard-conforming. Edits are provided to correct this oversight. EDITS: All edits refer to 04-007. [162:17] Change "" to "". [162:19] After "", insert "or ". [162:20] After "", insert "or ". [162:21] After "", insert "or ". SUBMITTED BY: Rob James HISTORY: 04-411 m170 F03/0025 Submitted 04-411r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0026 TITLE: Intrinsic types in CLASS IS type guard statements KEYWORDS: CLASS IS, type guard, SELECT TYPE, intrinsic type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: PROGRAM foo CLASS(*), POINTER :: x INTEGER, TARGET :: i x =3D> i SELECT TYPE (x) CLASS IS (INTEGER) PRINT *, 'How can INTEGER be a class?' END SELECT END The description of a CLASS IS type guard statement refers to an extension of the type specified. This makes no sense for nonextensible types. C815 disallows all nonextensible derived types, but nothing disallows intrinsic types, which are also nonextensible. Was this program intended to be standard-conforming? ANSWER: No, this program was not intended to be standard-conforming. Edits are supplied to correct this oversight. EDITS: All edits refer to 04-007. Note that these edits are the same as the edits proposed for F03/0025. [162:17] Change "" to "". [162:19] After "", insert "or ". [162:20] After "", insert "or ". [162:21] After "", insert "or ". SUBMITTED BY: Rob James HISTORY: 04-412 m170 F03/0026 Submitted 04-412r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0027 TITLE: Assumed character length in type guard statements KEYWORDS: CHARACTER, assumed length, type guard, SELECT TYPE DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: PROGRAM foo CHARACTER, TARGET :: c CLASS(*), POINTER :: p p =3D> c SELECT TYPE (p) TYPE IS (CHARACTER(*)) PRINT *, 'Character of length ', LEN(p) END SELECT END Constraint C814 says that, in a type guard statement, the shall specify that each length type parameter is assumed. Constraint C416 does not list a type guard statement as a context in which "*" can be used as a length type parameter for a character. Was this program intended to be standard-conforming? ANSWER: Yes, this program was intended to be standard-conforming. Edits are supplied to correct this oversight. EDITS: All edits refer to 04-007. These edits assume that the edits for F03/0026 are passed. [41:9] Remove "or". [41:9+] Add a new list item: "(3.5) in the or of a type guard statement (8.1.5), or" [41:33+] Add a new list item: "(3.5) If used in the of a type guard statement, the associating entity assumes its length from the selector." SUBMITTED BY: Rob James HISTORY: 04-413 m170 F03/0027 Submitted 04-413r1 m170 Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 - fix edits N1663 Reaffirmed in WG5 ballot N1661 on N1660 - fix edits ---------------------------------------------------------------------- NUMBER: F03/0028 TITLE: Commas in complex namelist output KEYWORDS: Namelist, complex formatting, comma, semicolon DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The 7th paragraph in 10.9.2 for list directed output says: "Complex constants are enclosed in parentheses with a separator between the real and imaginary parts, each produced as defined above for real constants. The separator is a comma if the decimal edit mode is POINT; it is a semicolon if the decimal edit mode is COMMA." There are similar words in most other places where complex formatting is described. The second paragraph of 10.10.1.3 Namelist group object list items says: "When the next effective item is of type complex, the input form of the input value consists of a left parenthesis followed by an ordered pair of numeric input fields separated by a comma and followed by a right parenthesis. " Other places correctly describe namelist complex output as having a separator, either a comma or a semicolon, depending on the decimal edit mode. Should the namelist version be reworded to say "comma or semicolon"? ANSWER: Yes. Edits are supplied to correct this oversight. In addition, a similar issue exists for list directed input of undelimited character values and namelist output of character values. EDITS: All edits refer to 04-007. [240:13] Replace "comma" with "comma (if the decimal edit mode is POINT), semicolon (if the decimal edit mode is COMMA)". [244:29] Replace "a comma" by "a comma (if the decimal edit mode is POINT) or a semicolon (if the decimal edit mode is COMMA),". [244:30] Before "The first", add the following sentence: The separator is a comma if the decimal edit mode is POINT; it is a semicolon if the decimal edit mode is COMMA. [244:32] Replace "comma" with "separator". [244:33] Replace "comma" with "separator". [245:4] After "comma," insert " semicolon,". SUBMITTED BY: Dick Hendrickson HISTORY: 04-409 m170 F03/0028 Submitted 04-409r1 m170 Passed by J3 meeting 05-146 m171 Failed interp letter ballot #10 05-164 m171 Passed by J3 meeting 05-170 m172 Failed J3 letter ballot #11 05-257 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 - fix edits N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0029 TITLE: Negative zero and intrinsic functions KEYWORDS: Negative zero, IEEE, intrinsic functions DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: 4.4.2 states "Processors that distinguish between positive and negative zeros shall treat them as equivalent ... as actual arguments to intrinsic procedures other than those for which it is explicitly specified that negative zero is distinguished" Q1. Does this mean that TRANSFER(-0.0,42) is required to give the same answer as TRANSFER(+0.0,42)? The definition of TRANSFER has no explicit mention of negative zero. Q2. Does this mean that MERGE(+0.0,-0.0,flag) always returns +0.0? Q3. Does this mean that SPREAD(-0.0,2) has the value [+0.0,+0.0] instead of [-0.0,-0.0]? Q4. Does this mean that RESHAPE([-0.0],[1]) has the value [+0.0] instead of [-0.0]? Q5. Does this mean that SET_EXPONENT(-0.0,10) is +0.0 not -0.0? Q6. Does this mean that if a REAL variable X has a negative zero value, REAL(x,...) has a positive zero value? Q7. Does this mean that CMPLX(0,-0.0) has the value (+0.0,+0.0) instead of (+0.0,-0.0)? Q8. Does this mean that if a complex variable C has a negative zero imaginary part, that AIMAG(C) returns +0.0 instead of -0.0? Q9. In any other intrinsic function, if the definition of the intrinsic would imply a different result for negative zero than for positive zero, does this mean that the function returns the positive zero answer for a negative zero argument? ANSWER: Q1. No. The definition of TRANSFER explicitly states that its result has the same physical representation as its first argument. This would not be possible if "equivalent" meant that the exact same result had to be produced. Q2. No, this would contradict the definition of MERGE. Q3. No. SPREAD "replicates" its argument, which means that the value of each copy is the same as the original, not just compare equal. As with TRANSFER, this would not be possible with the suggested interpretation of the text in 4.4.2. Q4+. No. As with the previous questions, this would require an overly strict interpretation of the term "equivalent", contradicting the clear intent of the function in question. DISCUSSION: The term "equivalent" in the quoted text in 4.4.2 refers to the concept of mathematical equivalence, not physical or computational equivalence. A clarifying edit is supplied. EDITS: [38:2] Before "equivalent" insert "mathematically". SUBMITTED BY: Malcolm Cohen HISTORY: 04-422 m170 F03/0029 Submitted - Passed by J3 meeting 05-146 m171 Passed J3 letter ballot #10 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0045 TITLE: Finalization and assumed-size arguments with INTENT(OUT) KEYWORDS: finalization, INTENT(OUT), assumed size, dummy argument DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER :: i CONTAINS FINAL :: finalizeT END TYPE CONTAINS ELEMENTAL SUBROUTINE finalizeT(f) TYPE(t), INTENT(INOUT) :: f f%i =3D 10 END SUBROUTINE END MODULE SUBROUTINE xyz (d) USE m TYPE(t), INTENT(OUT) :: d(*) END SUBROUTINE PROGRAM foo USE m EXTERNAL xyz TYPE(t) :: a(10) =3D t(5) CALL xyz(a(2)) END PROGRAM 4.5.5.2 of Fortran 2003 states: When a procedure is invoked, a nonpointer, nonallocatable object that is an actual argument associated with an INTENT(OUT) dummy argument is finalized. For assumed-size arguments, this situation is similar to that of default initialization with INTENT(OUT). Default initialization is prohibited for INTENT(OUT), assumed-size dummy arguments by C544. A similar restriction on finalization may have been overlooked. Was this program intended to be standard-conforming? ANSWER: No, this program was not intended to be standard-conforming. An edit is supplied to correct this oversight. DISCUSSION: The unstated philosophy of assumed-size arrays in the standard is that no action is allowed on an assumed-size array which would need to be applied elementally to the whole array. That is why no whole array assignment is allowed, for example. In accordance with this philosophy, (1) types with ultimate allocatable components also need to be excluded from being INTENT(OUT) assumed-size, as procedure invocation in this case requires deallocation of all the allocated components. (2) polymorphic INTENT(OUT) assumed-size arrays should also be excluded, as they might have finalisation, default initialisation or allocatable components. This interp subsumes Fortran 2003 interp #0060. EDITS: All edits refer to 04-007. [80:9] Before "of a type", insert "polymorphic, of a finalizable type, of a type with an ultimate allocatable component, or". SUBMITTED BY: Rob James HISTORY: 05-136 m171 F03/0045 Submitted, passed by J3 meeting 05-170 m172 Passed J3 letter ballot #11 N1622 m172 Failed WG5 ballot N1629 05-256 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0056 TITLE: Null input values and list-directed UDDTIO KEYWORDS: null value, UDDTIO DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m PRIVATE TYPE, PUBLIC :: t INTEGER i INTEGER j CONTAINS PROCEDURE, PRIVATE :: readFormatted =3D> readFormattedT GENERIC :: READ(FORMATTED) =3D> readFormatted END TYPE CONTAINS SUBROUTINE readformattedT(dtv, unit, iotype, v_list, iostat, = iomsg) CLASS(t), INTENT(INOUT) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(*), INTENT(INOUT) :: iomsg READ (unit, *) dtv%i READ (unit, *) dtv%j END SUBROUTINE END MODULE PROGRAM p USE m INTEGER i TYPE(t) x, y, z x%i =3D 10 x%j =3D 15 y%i =3D 20 y%j =3D 25 z%i =3D 30 z%j =3D 35 i =3D 100 READ (*,*) x, y, z, i PRINT *, x, y, z, i END PROGRAM The following is given as input to this program: 1044 2167 3977 / 1 2 3 10.9.1.1 of Fortran 2003 (Null values) states: A slash encountered as a value separator during execution of a list-directed input statement causes termination of execution of that input statement after the assignment of the previous value. If a child data transfer statement encounters a slash as a value separator, it is unclear whether this statement applies to just the child statement, or to the parent data transfer statement as well. The significance for any subsequent child statement is also unclear. What is the behaviour of this program when it is given the specified input? ANSWER: When a child data transfer statement encounters a slash as a value separator, only that data transfer statement encounters the slash. None of its parent data transfer statements encounters the slash. Only the data transfer statement that encounters the slash is terminated. The program above should print the following: 1044.2167.3977.25.1.2.3 where "." represents a value separator. EDITS: None. SUBMITTED BY: Rob James HISTORY: 05-171 m172 F03/0056 Submitted 05-218 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0057 TITLE: Namelist I/O and UDDTIO KEYWORDS: namelist, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Can namelist I/O ever invoke a user-defined derived-type I/O procedure? 10.10.1.2 of Fortran 2003 (Namelist input values) implies that namelist input cannot invoke a user-defined derived-type I/O procedure. It says that, for a derived-type variable, "the effect is as if the variable represented were expanded into a sequence of scalar list items of intrinsic data types", which would preclude any derived-type I/O. However, the same sentence says that this is done "in the same way that formatted input/output list items are expanded (9.5.2)", which would result in some effective list items of derived type. 9.5.3.6 and 9.5.3.7.2 also imply that a user-defined derived-type I/O procedure could be invoked for a namelist group object. ANSWER: Yes, namelist I/O can invoke a user-defined derived-type I/O procedure. Edits are provided to correct this problem. EDITS: All edits refer to 04-007. [244:8] Remove "of intrinsic data types". [244:10] Remove "intrinsic". SUBMITTED BY: Rob James HISTORY: 05-172 m172 F03/0057 Submitted 05-219 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0058 TITLE: Recursive namelist output KEYWORDS: UDDTIO, namelist, output DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE mod PRIVATE TYPE, PUBLIC :: node INTEGER :: value =3D 0 CONTAINS PROCEDURE, PRIVATE :: nodeFormattedWrite =3D> writeroutine GENERIC :: WRITE(FORMATTED) =3D> nodeFormattedWrite END TYPE CONTAINS SUBROUTINE writeroutine(dtv, unit, iotype, vlist, iostat, = iomsg) CLASS(node), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(LEN=3D*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(LEN=3D*), INTENT(INOUT) :: iomsg REAL a NAMELIST /inner/ a a =3D 4.0 WRITE(unit, NML=3Dinner) END SUBROUTINE END MODULE PROGRAM foo USE mod TYPE(node) :: a(2) NAMELIST /outer/ a a(1)%value =3D 1 a(2)%value =3D 2 WRITE(*, NML=3Douter) END PROGRAM Is the following output standard-conforming for the above program? If not, please give an example of standard-conforming output. &OUTER A=3D &INNER A=3D4.000000000 /, &INNER A=3D4.000000000 / / ANSWER: Yes EDITS: None SUBMITTED BY: Rob James HISTORY: 05-173 m172 F03/0058 Submitted 05-220 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0060 TITLE: Default initialization of INTENT(OUT), assumed-size arrays KEYWORDS: default initialization, INTENT(OUT), assumed size, = polymorphism DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE base INTEGER I END TYPE TYPE, EXTENDS(base) :: child INTEGER :: j =3D 5 END TYPE CONTAINS SUBROUTINE sub(b) CLASS(base), INTENT(OUT) :: b(*) END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(child) :: c(3) c%i =3D 12 c%j =3D 47 CALL sub(c) PRINT *, c%j END PROGRAM C544 prevents nonpolymorphic, INTENT(OUT), assumed-size arrays from having default initialization. The polymorphic case, however, is not checkable at compile time, so it cannot be a constraint. Was it intended that the dynamic type of an INTENT(OUT), assumed-size array could have default initialization? If so, what does the above program print? ANSWER: No, this was not intended. This interp is subsumed by Fortran 2003 interp # 45, which contains edits making the above example non-conforming. EDITS: None SUBMITTED BY: Rob James HISTORY: 05-175 m172 F03/0060 Submitted 05-222 m173 Edit provided 05-222r1 m173 Subsumed by 0045 - Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0061 TITLE: Polymorphism and explicit-shape or assumed-size dummy arguments KEYWORDS: polymorphism, assumed size, actual argument, dummy argument DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE t1 INTEGER :: i END TYPE CONTAINS SUBROUTINE abc (b) CLASS(t1) :: b(*) EXTERNAL xyz CALL xyz(b(2)) END SUBROUTINE END MODULE SUBROUTINE xyz(d) USE m TYPE(t1) :: d(2,3) END SUBROUTINE PROGRAM foo USE m TYPE, EXTENDS(t1) :: t2 INTEGER :: j END TYPE TYPE(t2) a(10) CALL abc(a(2)) END PROGRAM During the execution of "xyz", the dummy argument "d" is sequence associated with the associated actual argument (which is true if "d" has either explicit shape or assumed size). This implies that the entity that is argument associated with "d" must be contiguous. The dummy argument "b" of the module subroutine "abc" is polymorphic, and its dynamic type in this case is different than its declared type. In this scoping unit, "xyz" has an implicit interface, so we know it doesn't have any polymorphic arguments. So, the dummy argument of "xyz" must be nonpolymorphic, and have the same declared type as the actual argument (b(2)). This implies that we only want to pass the parent portion of b(2). But the dummy argument of "xyz" may be an explicit-shape or assumed-size array (in this case, it is an explicit-shape array). This means that we have to pass a contiguous array to "xyz". This wouldn't be a problem if the dynamic type of "b" was the same as the declared type, but in this case it is not. The parent portion of "b" (from element 2 to the end of the array) must be copied into a temporary array. The compiler cannot possibly know how big "b" is because it is an assumed-size array, so it is impossible to make such a copy. Was this program intended to be standard-conforming? ANSWER: No, this program was not intended to be standard-conforming. Edits are provided to correct this oversight. EDITS: All edits refer to 04-007. [270:27] Change "assumed-shape or pointer" to "assumed-shape, pointer, or polymorphic". SUBMITTED BY: Rob James HISTORY: 05-176 m172 F03/0061 Submitted 05-223 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0062 TITLE: Finalization of array constructors KEYWORDS: Finalization, array constructor DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider the following program: MODULE m TYPE t INTEGER i CONTAINS FINAL :: finalizeT END TYPE CONTAINS SUBROUTINE finalizeT(obj) TYPE(t) :: obj(:) PRINT *, 'Finalizing a rank-1 array of type t' END SUBROUTINE END MODULE PROGRAM foo USE m TYPE(t) :: a a%i =3D 5 PRINT *, (/ (a, i=3D1,5) /) END PROGRAM If the PRINT statement in the main program was printing a function result or a structure constructor, rather than an array constructor, it is clear that the object should be finalized after that PRINT statement. However, for array constructors, this does not appear to be the case. In the main program above, should the entity created by the array constructor be finalized after execution of the PRINT statement? ANSWER: Yes, the array constructor should be finalized. Edits are provided to correct this oversight. EDITS: This edit refers to 04-007. [59:27] After the first occurrence of "structure constructor", insert "or array constructor". On the same line, delete the second occurrence of "structure". This edit refers to the edit introduced by interpretation F03/0007. After the first occurrence of "structure constructor", insert "or array constructor". In the same sentence, delete the = second occurrence of "structure". SUBMITTED BY: Rob James HISTORY: 05-177 m172 F03/0062 Submitted 05-224 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 - fix edits N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0066 TITLE: Precision of operation KEYWORDS: precision, operation DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: Given REAL X X =3D ... some value ... IF( (X+3.0) .EQ. 3.0 )... =20 may the X+3.0 be computed with more range and/or precision than that of REAL? In other words, is PRECISION(X) .EQ. PRECISION(X+3.0) always true; or is PRECISION(X) .LT. PRECISION(X+3.0) sometimes true? References are to J3/04-007. 2.4.1.1 Intrinsic type has "The kind type parameter indicates ... the decimal precision and exponent range for the real and complex types, ..." 7.1.4.2 Type, type parameters, and shape of the result of an operation has in (4) "For an expression x1 op x2 where op is a numeric intrinsic binary operator with both operands of the same type and kind type parameters, ..., the kind type parameter of the expression is identical to that of each operand." Since X and 3.0 are the same type and have the same kind type parameters, 7.1.4.2 (4) appears to require the X+3.0 have just the range and precision of REAL; no more, no less (otherwise, the precision is not identical). But, several members of the J3 email list have said that the "+" may be done with more precision; using either 1.4(6) or 7.1.8.3 as the reason. Perhaps something alone the lines of "The values of floating operands and of the results of floating expressions may be represented in greater precision and range than that required by the kind type parameter; the kind type parameter is not changed thereby." should be added to 7.1.4.2(4). QUESTION: Is PRECISION(X) .EQ. PRECISION(X+3.0) always true?=20 ANSWER: Yes, that is the definition of PRECISION. The PRECISION intrinsic has nothing to do with the precision in which the computation X+3.0 is computed. 7.1.4.2 (4) only describes the precision of the end result of the computation. The weasel words in 1.4 (6) allow the processor to compute this = expression in higher precision than REAL. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-193 m173 F03/0066 Submitted 05-193r1 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0067 TITLE: Accuracy of conversion of real literal constants KEYWORDS: conversion, accuracy DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot QUESTION: The following is independent of IEEE-754. Fortran 2003 10.6.1.2.6 covers conversions between "decimal values" and "internal values" and has some strong requirements. Are there equivalent requirements on accuracy for conversions of real literal constants? Sections 4.1.2 and 4.4.2 seems like the places to find them (if they exist). What rounding mode is used for conversions of real literal constants? Is the same rounding mode used for all such conversions? The following four questions are about positive values, but the same would apply to negative values. Must all "decimal values" in the range smallest non-zero finite internal value (which could be a denormal) to largest finite internal value, e.g. 0.1, be converted? Must all "decimal values" in the range zero to smallest non-zero finite internal value, e.g. 1.0e-999999999, be converted? Must all "decimal values" larger than the largest finite internal value, e.g. 9.9e+99999999999, be converted if infinity is an internal value? What does nearest rounding mean for these cases? What requirements exist for "decimal values" larger than the largest finite internal value if infinity is not an internal value? ANSWER: There are no requirements on accuracy for conversions of real literal constants. The standard does not specify the rounding mode used for conversions of real literal constants, nor does it require the same rounding mode to be used for all conversions. Whether all decimal values in any range can be converted is not standardized. There are no requirements for "decimal values" larger than the largest finite internal value whether infinity is an internal value or not. EDITS: None SUBMITTED BY: Fred Tydeman HISTORY: 05-206 m173 F03/0067 Submitted 05-206r1 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0068 TITLE: First character of namelist output records KEYWORDS: namelist, output, UDDTIO DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: The last sentence of 10.10.2.2 of Fortran 2003 states: Except for continuation of delimited character sequences, each output record begins with a blank character. If a namelist output statement causes a user-defined derived-type output procedure to be called, was it intended to be standard- conforming for that procedure to create a new record (perhaps by using the slash edit descriptor) that does not begin with a blank character? ANSWER: Yes, this situation was intended to be standard-conforming. Explicit formatting in user-defined derived-type output is not required to output a leading blank in this case. An edit is provided to correct this oversight. EDITS: All edits refer to 04-007. [247:33] Before "continuation", insert "new records created by explicit formatting within a user-defined derived-type output procedure or by". SUBMITTED BY: Rob James HISTORY: 05-227 m173 F03/0068 Submitted 05-227r1 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 =20 ---------------------------------------------------------------------- NUMBER: F03/0069 TITLE: Procedure pointers in defined assignment KEYWORDS: procedure pointer, defined assignment DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: In 12.3.2.1.1 of Fortran 2003, at [262:8-9], the following is stated about the dummy arguments of a function that defines an operation: The dummy arguments shall be nonoptional dummy data objects and shall be specified with INTENT (IN). This clearly states that a dummy argument of such a function cannot be a procedure pointer. The same is not stated for the dummy arguments of a subroutine that defines assignment. Was it intended that procedure pointers should be allowed in defined assignment, but not in defined operations? ANSWER: No. It was not intended that procedure pointers should be allowed in either defined assignment or defined operations. An edit is provided to correct this oversight. EDITS: All edits refer to 04-007. [263:6] Replace "Each argument shall be nonoptional." with "The dummy arguments shall be nonoptional dummy data objects." SUBMITTED BY: Rob James HISTORY: 05-228 m173 F03/0069 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0070 TITLE: Can child I/O statements be advancing I/O statements? KEYWORDS: UDDTIO, ADVANCE=3D DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot [175:30-31] of Fortran 2003 states: An advancing input/output statement always positions a record file after the last record read or written, unless there is an error condition. Since a child I/O statement does not position a file after the last Record [194:19][199:8-9], this implies that a child I/O statement = cannot=20 be an advancing I/O statement. [189:6-9] of Fortran 2003 states: The ADVANCE=3D specifier determines whether advancing input/output occurs for this input/output statement. If YES is specified, advancing input/output occurs. If NO is specified, nonadvancing input/output occurs (9.2.3.1). If this specifier is omitted from an input/output statement that allows the specifier, the default value is YES. This clearly states that any data transfer statement is an advancing I/O statement if the value 'NO' is not specified for the ADVANCE=3D specifier. These two statements seem to contradict each other.=20 QUESTION: If a child I/O statement does not have an ADVANCE=3D specifier with the value 'NO', is it an advancing I/O statement? DISCUSSION: The answer to this question affects the value for the IOSTAT variable for child READ statements in some situations. For example, in the following program, the value of "stat1" should be equal to IOSTAT_EOF if the child READ statement is advancing, but it should be equal to IOSTAT_EOR if the statement is nonadvancing. MODULE m TYPE t CHARACTER(2) :: x(2) CONTAINS PROCEDURE :: readT GENERIC :: READ(FORMATTED) =3D> readT END TYPE CONTAINS SUBROUTINE readT(dtv, unit, iotype, v_list, iostat, iomsg) CLASS(t), INTENT(INOUT) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER(*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: v_list(:) INTEGER, INTENT(OUT) :: iostat CHARACTER(*), INTENT(INOUT) :: iomsg READ (unit, '(2a2)', IOSTAT=3Diostat) dtv%x END SUBROUTINE END MODULE PROGRAM p USE m USE, INTRINSIC :: ISO_FORTRAN_ENV TYPE(t) t1 CHARACTER(3) :: c =3D '123' INTEGER stat1 READ (c, *, IOSTAT=3Dstat1) t1 PRINT *, (stat1 =3D=3D IOSTAT_EOR), (stat1 =3D=3D IOSTAT_EOF) END PROGRAM ANSWER: No, such a child I/O statement is not advancing. Edits are provided to correct this inconsistency. EDITS: All edits refer to 04-007. [189:7] Replace "this input/output statement" by "a nonchild input/output statement". [189:9] Replace "from an input/output statement" by "from a nonchild input/output statement". [189:9] After "YES." Insert " A formatted child input/output statement is a nonadvancing input/output statement, and any ADVANCE=3D specifier is ignored." [199:8+] Add a new bullet: " o Any ADVANCE=3D specifier in a child input/output statement = is ignored." SUBMITTED BY: Rob James HISTORY: 05-229 m173 F03/0070 Submitted 05-229r1 m173 Passed by J3 meeting 06-133 m175 Passed J3 letter ballot #12 - typos fixed N1658 m176 Passed WG5 ballot N1657 - fix edits N1663 Reaffirmed in WG5 ballot N1661 on N1660 ---------------------------------------------------------------------- NUMBER: F03/0072 TITLE: Default initialization for "automatic" components KEYWORDS: Parameterized Derived Type, Default Initialization DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot QUESTION: Consider TYPE t(len) INTEGER,LEN :: len CHARACTER(len) :: cvalue =3D "xyz" END TYPE SUBROUTINE s(n) TYPE(t(n)) x ... TYPE t2(len2) TYPE(t(len2)) :: tvalue =3D t(10,"fred nurke") END TYPE SUBROUTINE s2(n) TYPE(t2(n)) :: y ... The type definition for T appears to conform to the standard; it allows an "automatic" component to be default initialized. However, the declaration of the local variable X in subroutine S will initialize the component differently depending on the value of N, for example, giving the CVALUE component the value "", "x", "xy", "xyz", "xyz " for N being 0, 1, 2, 3, 4 respectively. Q1. Was it intended that "automatic" components can be default-initialized? If the answer is "Yes", the type definition for T2 also appears to conform to the standard. However, the declaration of Y in S2 will not work if N has any value other than 10 at run time. This is surprising; there appears to be no other situation where the runtime value of a length type parameter can render a declaration invalid. Q2. Is this situation intentional? ANSWER: Q1. No, this was not intended. An edit is supplied to fix this. Q2. Not applicable. EDITS: In 4.5.3 Components, immediately before R445 , insert a new constraint: [50:40+] "C447a (R440) If appears, every type parameter and array bound of the component shall be an initialization expression." SUBMITTED BY: Malcolm Cohen HISTORY: 05-285 m174 F03/0072 Submitted 05-285r1 m174 Revised edit 06-133 m175 Passed J3 letter ballot #12 N1658 m176 Passed WG5 ballot N1657 N1663 Reaffirmed in WG5 ballot N1661 on N1660 Sally Seitz Program Manager American National Standards Institute 25 West 43rd Street, 4th Floor New York, NY 10036 Tel: 212 642 4918 Fax: 212 840 2298 ------_=_NextPart_001_01C6AA73.CC113FA2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable N 4082-Defect Report 2 for ISO/IEC 1539-1: 2004, Programming = languages - Fortran

ISO/IEC JTC 1/SC22
Programming languages, their environments and system = software interfaces
Secretariat:=A0 U.S.A.=A0 (ANSI)
=A0
ISO/IEC JTC 1/SC22 N4082
=A0
TITLE:
Defect Report 2 for ISO/IEC 1539-1: 2004, = Programming languages - Fortran

DATE ASSIGNED:
2006-07-17
=A0
SOURCE:
SC 22/WG 5 Convener (J. Reid)

BACKWARD POINTER:
N/A
=A0
DOCUMENT TYPE:
Defect Report
=A0
PROJECT NUMBER:

=A0
STATUS:
For information and review when voting on N = 4080.

ACTION IDENTIFIER:
FYI
=A0
DUE DATE:
=A0
DISTRIBUTION:
TEXT

CROSS REFERENCE:
=A0
DISTRIBUTION FORM:
Def

_________end of cover sheet, beginning of = document___________

ISO/IEC JTC1/SC22/WG5 N1666
Defect Report 2 for Fortran 2003

All edits specified in this document relate to = WG5-N1601 (j3/04-007).
Other references to page and line numbers in general = refer to the
standard document as it was at the time of the = initial interpretation
request and/or subsequent interpretation = work.

---------------------------------------------------------------= -------
  
NUMBER: F03/0008
TITLE: Pointer assignment and arrays
KEYWORDS: pointer assignment, array, data-ref
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

There appears to be no explicit requirement that = the
<variable>s in R736 and R741 be scalar.  = If data-pointer-object
and proc-component ref were data-refs, then C614 = would prohibit
the <variable>s from being arrays.  = However, although the syntax
looks like a special case of a data-ref, nothing = appears to say
that R736 and R741 actually constitute = data-refs.

The standard gives no interpretation as to what the = meaning
would be in the case of an array.

Even when variable is a scalar, the standard does not = appear to
define what the properties (such as type and shape) = of a
data-pointer-object or proc-pointer-object are in = the case where
the syntax has a "%".  All we have is = a syntax with no
established meaning.

Q1. Is the <variable> in R736 or R741 allowed = to be an array?

Q2. Is the interpretation of the forms in R736 and = R741 the
    same as that of a = data-ref?

ANSWER:

A1. No.  The standard provides no interpretation = of what such
    a form would mean.  = Therefore, by the first sentence of
    1.5, it is not = standard-conforming.  Edits are provided to
    make this prohibition more = direct.

A2. Yes.

EDITS:

All edits refer to 04-007.

[143:12,24,35,37] Insert "<scalar->" = before "<variable>", four times.

SUBMITTED BY: Richard Maine

HISTORY: 04-333    m169  F03/0008 = Submitted
         = 04-333r1  m169  Passed by J3 meeting
         = 04-418r1  m170  Failed J3 letter ballot #9
         = 04-421    m170  Revised - Passed by J3 = meeting
         = 05-146    m171  Passed J3 letter ballot #10
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0012
TITLE:  Procedure pointers and the EXTERNAL = attribute
KEYWORDS: Procedure pointers, EXTERNAL
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Is the following program unit standard = conforming?

  SUBROUTINE SUB ( RPP )
    REAL, EXTERNAL, POINTER :: = RPP
    EXTERNAL :: PP
    POINTER :: PP
    PROCEDURE(REAL), POINTER :: PPP = =3D> NULL()
  END SUBROUTINE SUB

The last sentence of "5.1.2.6 EXTERNAL = attribute" appears to indicate
that it is allowed:

  "A procedure that has both the EXTERNAL = and POINTER attributes is a
  procedure pointer."

That the title of subclause 12.2.1.2 is = "Characteristics of dummy
procedures and dummy procedure pointers" = suggests that it is allowed.
That subclause continues "... whether it is a = pointer, ..." so it was
clearly envisioned that at least dummy procedures = could have the
POINTER attribute.

C1216 [264:30] appears to require PPP to be = allowed:

"C1216 (R1214) If =3D> appears in = <proc-decl>, the procedure entity
       shall have the = pointer attribute."

On the other hand, A conspiracy of C512 = [72:28-29]

"C512 (R501) If the POINTER attribute is = specified, the ALLOCATABLE,
      TARGET, EXTERNAL, or = INTRINSIC attribute shall not be
      = specified."

the second sentence of subclause 5.1.2.6 = [80:38-40]

  "This [EXTERNAL] attribute may also be = specified by ... a
  = <procedure-declaration-stmt>..."

the first paragraph of subclause 5.2 [85:15ff]

  "The combination of attributes that may = be specified for a
   particular entity is subject to the = same restrictions ...
   regardless of the method of = specification.  This also applies to
   the PROCEDURE, EXTERNAL and INTRINSIC = statements."

and the last sentence of the first paragraph of = 12.3.2.3 [264:8]

  "It [the procedure declaration statement] = specifies the EXTERNAL
  attribute...."

appears to completely wipe out procedure pointers = (PPP because of the
first paragraph of 12.3.2.3).

C521 [73:6-7] and C568 [91:5] also appear to prohibit = RPP and PP:

"C521 (R504) The <function-name> shall be = the name of an external
      function, a function = dummy procedure{, or a statement
      = function}."

"C568 (R541) A <proc-entity-name> shall = also be declared in a
      = <procedure-declaration-stmt>."

But then the first paragraph after R1210 (defining = the EXTERNAL
statement) [264:1] appears to allow RPP and = PP:

  "Each <external-name> shall be the = name of ... a procedure
   pointer...."

There is also a problem with protected procedure = pointers.  C535
clearly envisions their existence:

"C535 (R501) The PROTECTED attribute is = permitted only for a procedure
      = pointer...."

while C536 prohibits their existence:

"C536 (R501) If the PROTECTED attribute is = specified, the EXTERNAL ...
      attribute shall not = be specified."

ANSWER:

The discussion of procedure pointers is indeed = inconsistent.

The program unit is intended to be standard = conforming.  It was an
oversight during the development of the procedure = pointer facility
that the EXTERNAL attribute was not removed from = C512, that
"procedure pointer" was not added to C521, = that C535 and C536
contradict one another, and that an external = statement and specifying
the EXTERNAL attribute in a type declaration = statement were not
allowed in C568.  It is not helpful that the = last sentence of the
first paragraph of subclause 5.2 refers to = "PROCEDURE ... statements"
(which could be confused with the PROCEDURE = statement in an interface
block) where it should refer to "procedure = declaration ...
statements."

EDITS:

Delete ", EXTERNAL" from C512 = [72:28].

Insert ", a procedure pointer" after = "dummy procedure" in C521 [73:7].

Replace C536 [73:35-36]:

"C536 (R501) If the PROTECTED attribute is = specified, the INTRINSIC or
      PARAMETER attribute = shall not be specified.  If the PROTECTED
      and EXTERNAL = attributes are specified, the POINTER attribute
      shall also be = specified."

Replace the last sentence of the first paragraph of = subclause 5.2
[86:1] by "This also applies to procedure = declaration statements, and
to EXTERNAL and INTRINSIC statements."

Replace C568 [91:5]:

"C568 (R541) The EXTERNAL attribute (5.1.2.6) = shall be explicitly
      specified for a = <proc-entity-name>."

SUBMITTED BY:  Van Snyder

HISTORY: 04-358    m169  F03/0012 = Submitted
         = 04-358r2  m169  Revised
         = 04-418r1  m170  Failed J3 letter ballot #9
         = 04-401r2  m170  Passed by J3 meeting
         = 05-146    m171  Passed J3 letter ballot #10
         = N1658     m176  Passed WG5 ballot N1657 - fix = typo
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0020
TITLE: Kinds of intrinsic type parameters
KEYWORDS: type parameter, kind, intrinsic = type
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Q1. What are the kinds of the type parameters for = intrinsic types?

    In most contexts, it doesn't = matter. Fortran 95 did not even
    have the concept of the kind of a = type parameter or a context
    in which such a thing could be = detected in a
    standard-conforming = program.  Fortran 2003 added the concept
    in support of derived types. It = also added a syntax which
    exposes the question for = intrinsic types.

Q2. What is the KIND of a type parameter = inquiry?

Q3. For example, consider the program

      program = what_kind
        character = c
        write = (*,*) kind(c%kind) =3D=3D kind(0)
        write = (*,*) kind(c%len) =3D=3D kind(0)
      end

    Are both write statements = guaranteed to print .true. (meaning
    that the c%kind and c%len are of = default kind) or not?

For KIND parameters, although I can't find it = explicitly stated,
I see fairly strong evidence that all intrinsic kind = parameters
are intended to be default integers.  This = evidence is in the
intrinsic functions.  The KIND intrinsic = function and all the
selected_*_kind functions are specified to return = default
integers, which would make for some strangeness if = the kind
parameters were not default integer, in particular = if the KIND
intrinsic could not return the kind of its argument = because that
kind could not be represented in a default = integer.

There also seems no obvious benefit to having the = kind of the
intrinsic kind parameters be anything other than = default. In
practice, the number of supported values for kind is = small and
would have no trouble being represented in a default = integer;
large arrays of kind values are rare, so there isn't = much
benefit in using representations smaller than = default.

For character length, I see no similar = evidence.  Indeed, the
LEN intrinsic seems to suggest that lengths might be = other than
default integer. I believe that there was clear = intent to
facilitate (but not require) support for character = lengths
longer than could be expressed by a default = integer.

In most contexts, it doesn't directly matter what the = kind of
length is.  Parameter specifications in = type-specs don't have to
match in kind. So the user could specify and do = arithmetic on
lengths using whatever kind was appropriate for the = anticipated
problem sizes. The limit on maximum character length = is
processor-dependent anyway and is not necessarily = the same
as HUGE(whatever) (though it is a bit hard to = imagine how it
could usefully be larger).

The only context in which I can see that might matter = is in a
type parameter inquiry (6.1.3).  We don't = appear to have defined
the kind of a type parameter inquiry.  Although = we didn't say, I
am assuming that a type parameter inquiry ought to = "return" the
kind of the type parameter it is inquiring about. = Otherwise,
there would be no way to inquire about the type = parameter values
of some derived type variables (if the values didn't = fit in a
default integer).  We probably ought to = explicitly say, though.

ANSWER:

Q1. The kind parameters of all the intrinsic types = are of
    default integer kind. The kind = parameter of the intrinsic
    character length parameter is = processor-dependent.

    The support for this answer is as = described in the question.
    Edits are provided to make this = answer explicit.

Q2. The kind parameter of a type inquiry is the same = as that of
    the type parameter inquired = about. See page 123, lines 35-36.

Q3. The first write statement is guaranteed to print = a .true. value;
    it is processor dependent whether = the second one prints a .true.
    or .false. value.

EDITS:

All edits apply to 04-007.

At [36:14], [37:30], [39:15], [40:14], and [44:2], = insert the
following sentence before "The = kind":
    The kind type parameter is of = type default integer.

At [40:10], before "its", insert "its = kind is processor-dependent
and".

SUBMITTED BY: Richard Maine

HISTORY: 04-408    m170  F03/0020 = Submitted
         = 04-408r1  m170  Passed by J3 meeting
         = 05-146    m171  Passed J3 letter ballot #10
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0023
TITLE: IEEE_SET/GET_UNDERFLOW_MODE
KEYWORDS: IEEE, underflow mode
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Is it allowed for the argument of = IEEE_SET_UNDERFLOW_MODE or
IEEE_GET_UNDERFLOW_MODE to be an array?

There appears to be no restriction against arrays in = these
procedures.  For IEEE_SET_UNDERFLOW_MODE, it is = ill-defined
what an array would mean.  The wording implies = a scalar, in
that it talks about being true or false, but the = restriction
to scalars is not explicit. For = IEEE_GET_UNDERFLOW_MODE, it
could be defined, but seems a little silly and = nonparallel.

The similar procedures for rounding mode do = explicitly
specify that their arguments are scalar.

ANSWER:

No, arrays are not allowed for these arguments.  = Edits are provided
to correct this error.

EDITS:

[374:21] Add "scalar and" after "shall = be"
[380:13] Add "scalar and" after = "shall be"

SUBMITTED BY: Richard Maine

HISTORY: 04-420    m170  F03/0023 = Submitted - Passed by J3 meeting
         = 05-146    m171  Passed J3 letter ballot #10
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0025
TITLE: Abstract types in CLASS IS type guard = statements
KEYWORDS: ABSTRACT, CLASS IS, type guard, SELECT = TYPE
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      PROGRAM foo

        TYPE, = ABSTRACT :: base
          INTEGER = i
        END = TYPE
        TYPE, = EXTENDS(base) :: child
          INTEGER = j
        END = TYPE
        CLASS(*), = POINTER :: x
        = TYPE(child), TARGET :: c1

        x =3D> = c1
        SELECT = TYPE (x)
          CLASS = IS (base)
          &nb= sp; PRINT *, 'Class is base'
          CLASS = DEFAULT
          &nb= sp; PRINT *, 'Class is not base'
        END = SELECT

      END

Constraint C401 seems to prohibit the abstract type = "base" from
appearing in a CLASS IS type guard statement, thus = prohibiting this
program.  There seems to be no reason to = prohibit this, and allowing
it seems to be useful in some situations.

Was this program intended to be = standard-conforming?

ANSWER:

Yes, this program was intended to be = standard-conforming.  Edits are
provided to correct this oversight.

EDITS:

All edits refer to 04-007.
[162:17] Change "<type-spec>" to = "<derived-type-spec>".
[162:19] After "<type-spec>", insert = "or <derived-type-spec>".
[162:20] After "<type-spec>", insert = "or <derived-type-spec>".
[162:21] After "<type-spec>", insert = "or <derived-type-spec>".

SUBMITTED BY: Rob James

HISTORY: 04-411    m170  F03/0025 = Submitted
         = 04-411r1  m170  Passed by J3 meeting
         = 05-146    m171  Passed J3 letter ballot #10
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0026
TITLE: Intrinsic types in CLASS IS type guard = statements
KEYWORDS: CLASS IS, type guard, SELECT TYPE, = intrinsic type
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      PROGRAM foo

        CLASS(*), = POINTER :: x
        INTEGER, = TARGET :: i

        x =3D> = i
        SELECT = TYPE (x)
          CLASS = IS (INTEGER)
          &nb= sp; PRINT *, 'How can INTEGER be a class?'
        END = SELECT

      END

The description of a CLASS IS type guard statement = refers to an
extension of the type specified.  This makes no = sense for
nonextensible types.  C815 disallows all = nonextensible derived types,
but nothing disallows intrinsic types, which are = also nonextensible.

Was this program intended to be = standard-conforming?

ANSWER:

No, this program was not intended to be = standard-conforming.  Edits
are supplied to correct this oversight.

EDITS:

All edits refer to 04-007.  Note that these = edits are the same as the
edits proposed for F03/0025.

[162:17] Change "<type-spec>" to = "<derived-type-spec>".
[162:19] After "<type-spec>", insert = "or <derived-type-spec>".
[162:20] After "<type-spec>", insert = "or <derived-type-spec>".
[162:21] After "<type-spec>", insert = "or <derived-type-spec>".

SUBMITTED BY: Rob James

HISTORY: 04-412    m170  F03/0026 = Submitted
         = 04-412r1  m170  Passed by J3 meeting
         = 05-146    m171  Passed J3 letter ballot #10
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0027
TITLE: Assumed character length in type guard = statements
KEYWORDS: CHARACTER, assumed length, type guard, = SELECT TYPE
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      PROGRAM foo
        = CHARACTER, TARGET :: c
        CLASS(*), = POINTER :: p

        p =3D> = c
        SELECT = TYPE (p)
          TYPE IS = (CHARACTER(*))
          &nb= sp; PRINT *, 'Character of length ', LEN(p)
        END = SELECT
      END

Constraint C814 says that, in a type guard statement, = the <type-spec>
shall specify that each length type parameter is = assumed.

Constraint C416 does not list a type guard statement = as a context in
which "*" can be used as a length type = parameter for a character.

Was this program intended to be = standard-conforming?


ANSWER:

Yes, this program was intended to be = standard-conforming.  Edits are
supplied to correct this oversight.


EDITS:

All edits refer to 04-007.  These edits assume = that the edits for
F03/0026 are passed.

[41:9]   Remove "or".
[41:9+]  Add a new list item:
         = "(3.5) in the <type-spec> or <derived-type-spec> of a = type
          guard = statement (8.1.5),
         = or"
[41:33+] Add a new list item:
         = "(3.5) If used in the <type-spec> of a type guard = statement,
          the = associating entity assumes its length from the selector."


SUBMITTED BY: Rob James

HISTORY: 04-413    m170  F03/0027 = Submitted
         = 04-413r1  m170  Passed by J3 meeting
         = 05-146    m171  Passed J3 letter ballot #10
         = N1658     m176  Passed WG5 ballot N1657 - fix = edits
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660 - fix
          &nb= sp;           &nb= sp;   edits

---------------------------------------------------------------= -------

NUMBER: F03/0028
TITLE: Commas in complex namelist output
KEYWORDS: Namelist, complex formatting, comma, = semicolon
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

The 7th paragraph in 10.9.2 for list directed output = says:

"Complex constants are enclosed in parentheses = with a
separator between the real and imaginary parts, = each
produced as defined above for real constants. The = separator
is a comma if the decimal edit mode is POINT; it is = a
semicolon if the decimal edit mode is COMMA."

There are similar words in most other places where = complex
formatting is described.

The second paragraph of 10.10.1.3 Namelist group = object list
items says:

"When the next effective item is of type = complex, the input
form of the input value consists of a left = parenthesis
followed by an ordered pair of numeric input = fields
separated by a comma and followed by a right = parenthesis. "

Other places correctly describe namelist complex = output as
having a separator, either a comma or a semicolon, = depending
on the decimal edit mode.

Should the namelist version be reworded to say = "comma or
semicolon"?

ANSWER:

Yes.  Edits are supplied to correct this = oversight.
In addition, a similar issue exists for list = directed input of
undelimited character values and namelist output of = character
values.

EDITS:

All edits refer to 04-007.

[240:13] Replace "comma" with "comma = (if the decimal edit mode is
         = POINT), semicolon (if the decimal edit mode is COMMA)".

[244:29] Replace "a comma" by "a comma = (if the decimal edit mode
         is = POINT) or a semicolon (if the decimal edit mode is
         = COMMA),".
[244:30] Before "The first", add the = following sentence:
           = The separator is a comma if the decimal edit mode is
           = POINT; it is a semicolon if the decimal edit mode is
           = COMMA.
[244:32] Replace "comma" with = "separator".
[244:33] Replace "comma" with = "separator".

[245:4] After "comma," insert " = semicolon,".

SUBMITTED BY: Dick Hendrickson

HISTORY: 04-409    m170  F03/0028 = Submitted
         = 04-409r1  m170  Passed by J3 meeting
         = 05-146    m171  Failed interp letter ballot = #10
         = 05-164    m171  Passed by J3 meeting
         = 05-170    m172  Failed J3 letter ballot #11
         = 05-257    m173  Passed by J3 meeting
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657 - fix = edits
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0029
TITLE: Negative zero and intrinsic functions
KEYWORDS: Negative zero, IEEE, intrinsic = functions
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

4.4.2 states
  "Processors that distinguish between = positive and negative zeros
   shall treat them as equivalent ... as = actual arguments to intrinsic
   procedures other than those for which = it is explicitly specified
   that negative zero is = distinguished"

Q1. Does this mean that TRANSFER(-0.0,42) is required = to give the same
    answer as = TRANSFER(+0.0,42)?  The definition of TRANSFER has no
    explicit mention of negative = zero.

Q2. Does this mean that MERGE(+0.0,-0.0,flag) always = returns +0.0?

Q3. Does this mean that SPREAD(-0.0,2) has the value = [+0.0,+0.0]
    instead of [-0.0,-0.0]?

Q4. Does this mean that RESHAPE([-0.0],[1]) has the = value [+0.0]
    instead of [-0.0]?

Q5. Does this mean that SET_EXPONENT(-0.0,10) is +0.0 = not -0.0?

Q6. Does this mean that if a REAL variable X has a = negative zero
    value, REAL(x,...) has a positive = zero value?

Q7. Does this mean that CMPLX(0,-0.0) has the value = (+0.0,+0.0)
    instead of (+0.0,-0.0)?

Q8. Does this mean that if a complex variable C has a = negative zero
    imaginary part, that AIMAG(C) = returns +0.0 instead of -0.0?

Q9. In any other intrinsic function, if the = definition of the
    intrinsic would imply a different = result for negative zero than
    for positive zero, does this mean = that the function returns the
    positive zero answer for a = negative zero argument?

ANSWER:

Q1.  No.  The definition of TRANSFER = explicitly states that its result
     has the same physical = representation as its first argument.  This
     would not be possible if = "equivalent" meant that the exact same
     result had to be = produced.

Q2.  No, this would contradict the definition of = MERGE.

Q3.  No.  SPREAD "replicates" its = argument, which means that the value
     of each copy is the same as = the original, not just compare equal.
     As with TRANSFER, this = would not be possible with the suggested
     interpretation of the text = in 4.4.2.

Q4+.  No.  As with the previous questions, = this would require an
      overly strict = interpretation of the term "equivalent",
      contradicting the = clear intent of the function in question.

DISCUSSION:

The term "equivalent" in the quoted text in = 4.4.2 refers to the
concept of mathematical equivalence, not physical or = computational
equivalence.  A clarifying edit is = supplied.

EDITS:

[38:2] Before "equivalent" insert = "mathematically".

SUBMITTED BY: Malcolm Cohen

HISTORY: 04-422    m170  F03/0029 = Submitted - Passed by J3 meeting
         = 05-146    m171  Passed J3 letter ballot #10
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0045
TITLE: Finalization and assumed-size arguments with = INTENT(OUT)
KEYWORDS: finalization, INTENT(OUT), assumed size, = dummy argument
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

MODULE m
  TYPE t
    INTEGER :: i
  CONTAINS
    FINAL :: finalizeT
  END TYPE
CONTAINS
  ELEMENTAL SUBROUTINE finalizeT(f)
    TYPE(t), INTENT(INOUT) :: = f
    f%i =3D 10
  END SUBROUTINE
END MODULE

SUBROUTINE xyz (d)
  USE m
  TYPE(t), INTENT(OUT) :: d(*)
END SUBROUTINE

PROGRAM foo
  USE m
  EXTERNAL xyz
  TYPE(t) :: a(10) =3D t(5)
  CALL xyz(a(2))
END PROGRAM

4.5.5.2 of Fortran 2003 states:
    When a procedure is invoked, a = nonpointer, nonallocatable object
    that is an actual argument = associated with an INTENT(OUT) dummy
    argument is finalized.

For assumed-size arguments, this situation is similar = to that of
default initialization with INTENT(OUT).  = Default initialization is
prohibited for INTENT(OUT), assumed-size dummy = arguments by C544.  A
similar restriction on finalization may have been = overlooked.

Was this program intended to be = standard-conforming?

ANSWER:

No, this program was not intended to be = standard-conforming.  An edit
is supplied to correct this oversight.

DISCUSSION:

The unstated philosophy of assumed-size arrays in the = standard is that
no action is allowed on an assumed-size array which = would need to be
applied elementally to the whole array.  That = is why no whole array
assignment is allowed, for example.

In accordance with this philosophy,
(1) types with ultimate allocatable components also = need to be
    excluded from being INTENT(OUT) = assumed-size, as procedure
    invocation in this case requires = deallocation of all the
    allocated components.

(2) polymorphic INTENT(OUT) assumed-size arrays = should also be
    excluded, as they might have = finalisation, default initialisation
    or allocatable components.

This interp subsumes Fortran 2003 interp = #0060.

EDITS:

All edits refer to 04-007.

[80:9]  Before "of a type", = insert
        = "polymorphic, of a finalizable type, of a type with an
         = ultimate allocatable component, or".

SUBMITTED BY: Rob James

HISTORY: 05-136    m171  F03/0045 = Submitted, passed by J3 meeting
         = 05-170    m172  Passed J3 letter ballot #11
         = N1622     m172  Failed WG5 ballot N1629
         = 05-256    m173  Passed by J3 meeting
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0056
TITLE: Null input values and list-directed = UDDTIO
KEYWORDS: null value, UDDTIO
DEFECT TYPE: Interpretation
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      MODULE m
        = PRIVATE
        TYPE, = PUBLIC :: t
          INTEGER = i
          INTEGER = j
        = CONTAINS
          = PROCEDURE, PRIVATE :: readFormatted =3D> readFormattedT
          GENERIC = :: READ(FORMATTED) =3D> readFormatted
        END = TYPE
      CONTAINS
        = SUBROUTINE readformattedT(dtv, unit, iotype, v_list, iostat, = iomsg)
          = CLASS(t),     INTENT(INOUT) :: dtv
          = INTEGER,      INTENT(IN)    :: = unit
          = CHARACTER(*), INTENT(IN)    :: iotype
          = INTEGER,      INTENT(IN)    :: = v_list(:)
          = INTEGER,      INTENT(OUT)   :: = iostat
          = CHARACTER(*), INTENT(INOUT) :: iomsg
          READ = (unit, *) dtv%i
          READ = (unit, *) dtv%j
        END = SUBROUTINE
      END MODULE

      PROGRAM p
        USE = m
        INTEGER = i
        TYPE(t) = x, y, z
        x%i =3D = 10
        x%j =3D = 15
        y%i =3D = 20
        y%j =3D = 25
        z%i =3D = 30
        z%j =3D = 35
        i =3D = 100
        READ = (*,*) x, y, z, i
        PRINT *, = x, y, z, i
      END PROGRAM

The following is given as input to this = program:

1044 2167 3977 /
1 2 3


10.9.1.1 of Fortran 2003 (Null values) states:

    A slash encountered as a value = separator during execution of a
    list-directed input statement = causes termination of execution of
    that input statement after the = assignment of the previous value.

If a child data transfer statement encounters a slash = as a value
separator, it is unclear whether this statement = applies to just the
child statement, or to the parent data transfer = statement as well.
The significance for any subsequent child statement = is also unclear.

What is the behaviour of this program when it is = given the specified
input?


ANSWER:

When a child data transfer statement encounters a = slash as a value
separator, only that data transfer statement = encounters the slash.
None of its parent data transfer statements = encounters the slash.
Only the data transfer statement that encounters the = slash is
terminated.

The program above should print the following:
 1044.2167.3977.25.1.2.3
where "." represents a value = separator.


EDITS:

None.


SUBMITTED BY: Rob James

HISTORY: 05-171    m172  F03/0056 = Submitted
         = 05-218    m173  Passed by J3 meeting
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0057
TITLE: Namelist I/O and UDDTIO
KEYWORDS: namelist, UDDTIO
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Can namelist I/O ever invoke a user-defined = derived-type I/O
procedure?

10.10.1.2 of Fortran 2003 (Namelist input values) = implies that
namelist input cannot invoke a user-defined = derived-type I/O
procedure.  It says that, for a derived-type = variable, "the effect is
as if the variable represented were expanded into a = sequence of scalar
list items of intrinsic data types", which = would preclude any
derived-type I/O.

However, the same sentence says that this is done = "in the same way
that formatted input/output list items are expanded = (9.5.2)", which
would result in some effective list items of derived = type.

9.5.3.6 and 9.5.3.7.2 also imply that a user-defined = derived-type I/O
procedure could be invoked for a namelist group = object.


ANSWER:

Yes, namelist I/O can invoke a user-defined = derived-type I/O
procedure.  Edits are provided to correct this = problem.


EDITS:

All edits refer to 04-007.

[244:8]   Remove "of intrinsic data = types".

[244:10]  Remove "intrinsic".


SUBMITTED BY: Rob James

HISTORY: 05-172    m172  F03/0057 = Submitted
         = 05-219    m173  Passed by J3 meeting
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0058
TITLE: Recursive namelist output
KEYWORDS: UDDTIO, namelist, output
DEFECT TYPE: Interpretation
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      MODULE mod
        = PRIVATE
        TYPE, = PUBLIC :: node
         = ; INTEGER :: value =3D 0
        = CONTAINS
          = PROCEDURE, PRIVATE :: nodeFormattedWrite =3D> writeroutine
          GENERIC = :: WRITE(FORMATTED) =3D> nodeFormattedWrite
        END = TYPE
      CONTAINS
        = SUBROUTINE writeroutine(dtv, unit, iotype, vlist, iostat, iomsg)
          = CLASS(node), INTENT(IN) :: dtv
          = INTEGER, INTENT(IN) :: unit
          = CHARACTER(LEN=3D*), INTENT(IN) :: iotype
          = INTEGER, INTENT(IN) :: vlist(:)
          = INTEGER, INTENT(OUT) :: iostat
          = CHARACTER(LEN=3D*), INTENT(INOUT) :: iomsg

          REAL = a
          = NAMELIST /inner/ a
          a =3D = 4.0
          = WRITE(unit, NML=3Dinner)
        END = SUBROUTINE
      END MODULE

      PROGRAM foo
        USE = mod
        = TYPE(node) :: a(2)
        NAMELIST = /outer/ a
        = a(1)%value =3D 1
        = a(2)%value =3D 2
        WRITE(*, = NML=3Douter)
      END PROGRAM

Is the following output standard-conforming for the = above program?  If
not, please give an example of standard-conforming = output.

 &OUTER
 A=3D &INNER
 A=3D4.000000000
 /,  &INNER
 A=3D4.000000000
 /
 /

ANSWER:

Yes

EDITS:

None

SUBMITTED BY: Rob James

HISTORY: 05-173    m172  F03/0058 = Submitted
         = 05-220    m173  Passed by J3 meeting
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0060
TITLE: Default initialization of INTENT(OUT), = assumed-size arrays
KEYWORDS: default initialization, INTENT(OUT), = assumed size, polymorphism
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      MODULE m
        TYPE = base
          INTEGER = I
        END = TYPE
        TYPE, = EXTENDS(base) :: child
          INTEGER = :: j =3D 5
        END = TYPE
      CONTAINS
        = SUBROUTINE sub(b)
          = CLASS(base), INTENT(OUT) :: b(*)
        END = SUBROUTINE
      END MODULE

      PROGRAM foo
        USE = m
        = TYPE(child) :: c(3)
        c%i =3D = 12
        c%j =3D = 47
        CALL = sub(c)
        PRINT *, = c%j
      END PROGRAM

C544 prevents nonpolymorphic, INTENT(OUT), = assumed-size arrays from
having default initialization.  The polymorphic = case, however, is not
checkable at compile time, so it cannot be a = constraint.

Was it intended that the dynamic type of an = INTENT(OUT), assumed-size
array could have default initialization?  If = so, what does the above
program print?

ANSWER:

No, this was not intended.

This interp is subsumed by Fortran 2003 interp # = 45,
which contains edits making the above example = non-conforming.

EDITS:

None

SUBMITTED BY: Rob James

HISTORY: 05-175    m172  F03/0060 = Submitted
         = 05-222    m173  Edit provided
         = 05-222r1  m173  Subsumed by 0045 - Passed  by J3 = meeting
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0061
TITLE: Polymorphism and explicit-shape or = assumed-size dummy arguments
KEYWORDS: polymorphism, assumed size, actual = argument, dummy argument
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      MODULE m
        TYPE = t1
          INTEGER = :: i
        END = TYPE
      CONTAINS
        = SUBROUTINE abc (b)
          = CLASS(t1) :: b(*)
          = EXTERNAL xyz
          CALL = xyz(b(2))
        END = SUBROUTINE
      END MODULE

      SUBROUTINE = xyz(d)
        USE = m
        TYPE(t1) = :: d(2,3)
      END SUBROUTINE

      PROGRAM foo
        USE = m
        TYPE, = EXTENDS(t1) :: t2
          INTEGER = :: j
        END = TYPE
        TYPE(t2) = a(10)
        CALL = abc(a(2))
      END PROGRAM

During the execution of "xyz", the dummy = argument "d" is sequence
associated with the associated actual argument = (which is true if "d"
has either explicit shape or assumed size).  = This implies that the
entity that is argument associated with = "d" must be contiguous.

The dummy argument "b" of the module = subroutine "abc" is polymorphic,
and its dynamic type in this case is different than = its declared type.
In this scoping unit, "xyz" has an = implicit interface, so we know it
doesn't have any polymorphic arguments.  So, = the dummy argument of
"xyz" must be nonpolymorphic, and have the = same declared type as the
actual argument (b(2)).

This implies that we only want to pass the parent = portion of b(2).
But the dummy argument of "xyz" may be an = explicit-shape or
assumed-size array (in this case, it is an = explicit-shape array).

This means that we have to pass a contiguous array to = "xyz".  This
wouldn't be a problem if the dynamic type of = "b" was the same as the
declared type, but in this case it is not.  The = parent portion of "b"
(from element 2 to the end of the array) must be = copied into a
temporary array.

The compiler cannot possibly know how big = "b" is because it is an
assumed-size array, so it is impossible to make such = a copy.

Was this program intended to be = standard-conforming?

ANSWER:

No, this program was not intended to be = standard-conforming.  Edits
are provided to correct this oversight.

EDITS:

All edits refer to 04-007.

[270:27]  Change "assumed-shape or = pointer" to "assumed-shape,
          = pointer, or polymorphic".

SUBMITTED BY: Rob James

HISTORY: 05-176    m172  F03/0061 = Submitted
         = 05-223    m173  Passed by J3 meeting
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0062
TITLE: Finalization of array constructors
KEYWORDS: Finalization, array constructor
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider the following program:

      MODULE m
        TYPE = t
          INTEGER = i
        = CONTAINS
          FINAL = :: finalizeT
        END = TYPE
      CONTAINS
        = SUBROUTINE finalizeT(obj)
          TYPE(t) = :: obj(:)
          PRINT = *, 'Finalizing a rank-1 array of type t'
        END = SUBROUTINE
      END MODULE

      PROGRAM foo
        USE = m
        TYPE(t) = :: a
        a%i =3D = 5
        PRINT *, = (/ (a, i=3D1,5) /)
      END PROGRAM

If the PRINT statement in the main program was = printing a function
result or a structure constructor, rather than an = array constructor,
it is clear that the object should be finalized = after that PRINT
statement.

However, for array constructors, this does not appear = to be the case.
In the main program above, should the entity created = by the array
constructor be finalized after execution of the = PRINT statement?

ANSWER:

Yes, the array constructor should be finalized.  = Edits are provided to
correct this oversight.

EDITS:

This edit refers to 04-007.

[59:27]  After the first occurrence of = "structure constructor", insert
         = "or array constructor".  On the same line, delete the = second
         = occurrence of "structure".

This edit refers to the edit introduced by = interpretation F03/0007.

         = After the first occurrence of "structure constructor", = insert
         = "or array constructor". In the same sentence, delete the = second
         = occurrence of "structure".

SUBMITTED BY: Rob James

HISTORY: 05-177    m172  F03/0062 = Submitted
         = 05-224    m173  Passed by J3 meeting
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657 - fix = edits
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0066
TITLE: Precision of operation
KEYWORDS: precision, operation
DEFECT TYPE: Interpretation
STATUS: Passed by WG5 ballot

QUESTION:

Given
  REAL X
  X =3D ... some value ...
  IF( (X+3.0) .EQ. 3.0 )... 
may the X+3.0 be computed with more range and/or = precision than that
of REAL?  In other words, is PRECISION(X) .EQ. = PRECISION(X+3.0) always
true; or is PRECISION(X) .LT. PRECISION(X+3.0) = sometimes true?

References are to J3/04-007.

2.4.1.1 Intrinsic type has "The kind type = parameter indicates ... the
decimal precision and exponent range for the real = and complex types,
..."

7.1.4.2 Type, type parameters, and shape of the = result of an operation
has in (4) "For an expression x1 op x2 where op = is a numeric intrinsic
binary operator with both operands of the same type = and kind type
parameters, ..., the kind type parameter of the = expression is
identical to that of each operand."

Since X and 3.0 are the same type and have the same = kind type
parameters, 7.1.4.2 (4) appears to require the X+3.0 = have just the
range and precision of REAL; no more, no less = (otherwise, the
precision is not identical).  But, several = members of the J3 email
list have said that the "+" may be done = with more precision; using
either 1.4(6) or 7.1.8.3 as the reason.

Perhaps something alone the lines of "The values = of floating operands
and of the results of floating expressions may be = represented in
greater precision and range than that required by = the kind type
parameter; the kind type parameter is not changed = thereby." should be
added to 7.1.4.2(4).

QUESTION:

Is PRECISION(X) .EQ. PRECISION(X+3.0) always true? =

ANSWER:

Yes, that is the definition of PRECISION.  The = PRECISION intrinsic has
nothing to do with the precision in which the = computation X+3.0 is
computed.  7.1.4.2 (4) only describes the = precision of the end result
of the computation.

The weasel words in 1.4 (6) allow the processor to = compute this expression
in higher precision than REAL.

EDITS:

None

SUBMITTED BY: Fred Tydeman

HISTORY: 05-193    m173  F03/0066 = Submitted
         = 05-193r1  m173  Passed by J3 meeting
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0067
TITLE: Accuracy of conversion of real literal = constants
KEYWORDS: conversion, accuracy
DEFECT TYPE: Interpretation
STATUS: Passed by WG5 ballot

QUESTION:

The following is independent of IEEE-754.

Fortran 2003 10.6.1.2.6 covers conversions between = "decimal values"
and "internal values" and has some strong = requirements.

Are there equivalent requirements on accuracy for = conversions of real
literal constants?  Sections 4.1.2 and 4.4.2 = seems like the places to
find them (if they exist).

What rounding mode is used for conversions of real = literal constants?
Is the same rounding mode used for all such = conversions?

The following four questions are about positive = values, but the same
would apply to negative values.

Must all "decimal values" in the range = smallest non-zero finite
internal value (which could be a denormal) to = largest finite internal
value, e.g. 0.1, be converted?

Must all "decimal values" in the range zero = to smallest non-zero
finite internal value, e.g. 1.0e-999999999, be = converted?

Must all "decimal values" larger than the = largest finite internal
value, e.g. 9.9e+99999999999, be converted if = infinity is an internal
value?  What does nearest rounding mean for = these cases?

What requirements exist for "decimal values"= larger than the largest
finite internal value if infinity is not an internal = value?

ANSWER:

There are no requirements on accuracy for conversions = of real literal
constants.

The standard does not specify the rounding mode used = for conversions
of real literal constants, nor does it require the = same rounding mode
to be used for all conversions.

Whether all decimal values in any range can be = converted is not
standardized.

There are no requirements for "decimal = values" larger than the largest
finite internal value whether infinity is an = internal value or not.

EDITS:

None

SUBMITTED BY: Fred Tydeman

HISTORY: 05-206    m173  F03/0067 = Submitted
         = 05-206r1  m173  Passed by J3 meeting
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0068
TITLE: First character of namelist output = records
KEYWORDS: namelist, output, UDDTIO
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

The last sentence of 10.10.2.2 of Fortran 2003 = states:
    Except for continuation of = delimited character sequences, each
    output record begins with a blank = character.

If a namelist output statement causes a user-defined = derived-type
output procedure to be called, was it intended to be = standard-
conforming for that procedure to create a new record = (perhaps by using
the slash edit descriptor) that does not begin with = a blank character?

ANSWER:

Yes, this situation was intended to be = standard-conforming.  Explicit formatting
in user-defined derived-type output is not required = to output a leading blank
in this case.  An edit is provided to correct = this oversight.

EDITS:

All edits refer to 04-007.

[247:33] Before "continuation", insert = "new records created by
         = explicit formatting within a user-defined derived-type
         = output procedure or by".

SUBMITTED BY: Rob James

HISTORY: 05-227    m173  F03/0068 = Submitted
         = 05-227r1  m173  Passed by J3 meeting
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660
 
---------------------------------------------------------------= -------

NUMBER: F03/0069
TITLE: Procedure pointers in defined = assignment
KEYWORDS: procedure pointer, defined = assignment
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

In 12.3.2.1.1 of Fortran 2003, at [262:8-9], the = following is stated
about the dummy arguments of a function that defines = an operation:
    The dummy arguments shall be = nonoptional dummy data objects and
    shall be specified with INTENT = (IN).

This clearly states that a dummy argument of such a = function cannot be
a procedure pointer.  The same is not stated = for the dummy arguments
of a subroutine that defines assignment.

Was it intended that procedure pointers should be = allowed in defined
assignment, but not in defined operations?

ANSWER:

No.  It was not intended that procedure pointers = should be allowed in
either defined assignment or defined = operations.  An edit is provided
to correct this oversight.

EDITS:

All edits refer to 04-007.

[263:6]  Replace "Each argument shall be = nonoptional." with
         = "The dummy arguments shall be nonoptional dummy data = objects."

SUBMITTED BY: Rob James

HISTORY: 05-228    m173  F03/0069 = Passed by J3 meeting
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0070
TITLE: Can child I/O statements be advancing I/O = statements?
KEYWORDS: UDDTIO, ADVANCE=3D
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

[175:30-31] of Fortran 2003 states:
    An advancing input/output = statement always positions a record file
    after the last record read or = written, unless there is an error
    condition.

Since a child I/O statement does not position a file = after the last
Record [194:19][199:8-9], this implies that a child = I/O statement cannot
be an advancing I/O statement.

[189:6-9] of Fortran 2003 states:
    The ADVANCE=3D specifier = determines whether advancing input/output
    occurs for this input/output = statement. If YES is specified,
    advancing input/output occurs. If = NO is specified, nonadvancing
    input/output occurs (9.2.3.1). If = this specifier is omitted from
    an input/output statement that = allows the specifier, the default
    value is YES.

This clearly states that any data transfer statement = is an advancing
I/O statement if the value 'NO' is not specified for = the ADVANCE=3D
specifier.

These two statements seem to contradict each other. =

QUESTION:

If a child I/O statement does not have an ADVANCE=3D = specifier with the
value 'NO', is it an advancing I/O statement?

DISCUSSION:

The answer to this question affects the value for the = IOSTAT variable
for child READ statements in some situations.  = For example, in the
following program, the value of "stat1" = should be equal to IOSTAT_EOF
if the child READ statement is advancing, but it = should be equal to
IOSTAT_EOR if the statement is nonadvancing.

      MODULE m
        TYPE = t
          = CHARACTER(2) :: x(2)
        = CONTAINS
          = PROCEDURE :: readT
          GENERIC = :: READ(FORMATTED) =3D> readT
        END = TYPE
      CONTAINS
        = SUBROUTINE readT(dtv, unit, iotype, v_list, iostat, iomsg)
          = CLASS(t), INTENT(INOUT) :: dtv
          = INTEGER, INTENT(IN) :: unit
          = CHARACTER(*), INTENT(IN) :: iotype
          = INTEGER, INTENT(IN)  :: v_list(:)
          = INTEGER, INTENT(OUT) :: iostat
          = CHARACTER(*), INTENT(INOUT) :: iomsg
          READ = (unit, '(2a2)', IOSTAT=3Diostat) dtv%x
        END = SUBROUTINE
      END MODULE

      PROGRAM p
        USE = m
        USE, = INTRINSIC :: ISO_FORTRAN_ENV
        TYPE(t) = t1
        = CHARACTER(3) :: c =3D '123'
        INTEGER = stat1
        READ (c, = *, IOSTAT=3Dstat1) t1
        PRINT *, = (stat1 =3D=3D IOSTAT_EOR), (stat1 =3D=3D IOSTAT_EOF)
      END PROGRAM

ANSWER:

No, such a child I/O statement is not = advancing.  Edits are provided
to correct this inconsistency.

EDITS:

All edits refer to 04-007.

[189:7]  Replace "this input/output = statement" by "a nonchild
         = input/output statement".

[189:9]  Replace "from an input/output = statement" by "from a
         = nonchild input/output statement".

[189:9]  After "YES." Insert
         = "  A formatted child input/output statement is a
           = nonadvancing input/output statement, and any ADVANCE=3D
           = specifier is ignored."

[199:8+] Add a new bullet:
         = " o Any ADVANCE=3D specifier in a child input/output statement = is
          &nb= sp;  ignored."

SUBMITTED BY: Rob James

HISTORY: 05-229    m173  F03/0070 = Submitted
         = 05-229r1  m173  Passed by J3 meeting
         = 06-133    m175  Passed J3 letter ballot #12 - typos = fixed
         = N1658     m176  Passed WG5 ballot N1657 - fix = edits
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660

---------------------------------------------------------------= -------

NUMBER: F03/0072
TITLE: Default initialization for = "automatic" components
KEYWORDS: Parameterized Derived Type, Default = Initialization
DEFECT TYPE: Erratum
STATUS: Passed by WG5 ballot

QUESTION:

Consider
  TYPE t(len)
    INTEGER,LEN :: len
    CHARACTER(len) :: cvalue =3D = "xyz"
  END TYPE

  SUBROUTINE s(n)
    TYPE(t(n)) x
    ...

  TYPE t2(len2)
    TYPE(t(len2)) :: tvalue =3D = t(10,"fred nurke")
  END TYPE

  SUBROUTINE s2(n)
    TYPE(t2(n)) :: y
    ...

The type definition for T appears to conform to the = standard; it
allows an "automatic" component to be = default initialized.  However,
the declaration of the local variable X in = subroutine S will
initialize the component differently depending on = the value of N, for
example, giving the CVALUE component the value = "", "x", "xy", "xyz",
"xyz " for N being 0, 1, 2, 3, 4 = respectively.

Q1. Was it intended that "automatic" = components can be
    default-initialized?

If the answer is "Yes", the type definition = for T2 also appears to
conform to the standard.  However, the = declaration of Y in S2 will not
work if N has any value other than 10 at run = time.  This is
surprising;  there appears to be no other = situation where the runtime
value of a length type parameter can render a = declaration invalid.

Q2. Is this situation intentional?

ANSWER:

Q1. No, this was not intended.  An edit is = supplied to fix this.

Q2. Not applicable.

EDITS:

In 4.5.3 Components, immediately before R445
<proc-component-def-stmt>, insert a new = constraint: [50:40+]
"C447a (R440) If = <component-initialization> appears, every type
          &nb= sp;   parameter and array bound of the component shall be = an
          &nb= sp;   initialization expression."

SUBMITTED BY: Malcolm Cohen

HISTORY: 05-285    m174  F03/0072 = Submitted
         = 05-285r1  m174  Revised edit
         = 06-133    m175  Passed J3 letter ballot #12
         = N1658     m176  Passed WG5 ballot N1657
         = N1663           = Reaffirmed in WG5 ballot N1661 on N1660


Sally Seitz
Program Manager
American National Standards Institute
25 West 43rd Street, 4th Floor
New York, NY 10036
Tel: 212 642 4918
Fax: 212 840 2298

------_=_NextPart_001_01C6AA73.CC113FA2--