PC file: 95-006a1.0 Archive: 95-006r1.A0 -------------------------------------------------------------------------------- NUMBER: 00000c TITLE: Minor edits and corrections KEYWORDS: typographical errors DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: ANSWER: EDITS: 18. In section 9.3.4.8 [117:27-28] change: 'READ specifies that the WRITE and ENDFILE statements must not refer to this connection.' to: 'READ specifies that the WRITE, PRINT, and ENDFILE statements must not refer to this connection.' Rationale: The same restriction applies to the PRINT statement. SUBMITTED BY: HISTORY: 93-289 m127 submitted items 4-5 94-034 m128 X3J3 ballot item 4 approved (moved to 00000b), 5 failed 94-028 m128 additional items 6-7 94-028r1 m128 approval of items 6-7 uc 94-084 m128 correction of item 5, approved uc 94-116 m129 X3J3 ballot items 5,6,7 approved 21-2 94-165 m129 submitted item 10, approved u.c. 94-161r2 m129 submitted items 11-17, approved u.c. 94-221 m130 X3J3 ballot approved 22-1 with edit to item 17 N984 m131 WG5 approved items 5-7 and items 10-17, moved to b 94-323 m131 submitted item 18, approved u.c. 95-034r1 m132 X3J3 ballot item 18, approved, 20-0, with edits -------------------------------------------------------------------------------- NUMBER: 00000e TITLE: Rejected Minor edits and corrections KEYWORDS: typographical errors DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Should the following be added to the list of edits? 8. In 13.13.85 RANGE change 'Returns the decimal exponent range in the model ...' to 'Returns the upper bound of the decimal exponent range of the model ...' [228:20] Rationale(1): a range has two values; RANGE returns only one. Rationale(2): there is not a decimal range in the model, see 13.7.1, but a decimal range can be calculated. Thus the change from 'in' to 'of'. 9. In 13.13.79 PRECISION change 'Returns the decimal precision in the model ...' to '............................. of .............' [226:4] Rationale: same as for RANGE, above. ANSWER: This item collects failed "minor edits and corrections" so as to not complicate voting on edits and corrections that are being considered. No, 8 and 9 should not be added. The use of 'range' is consistent with other uses in the standard and is meant to convey an entire range of values not just 2. The change from 'in' to 'of' is too small a change to be included at this time and would best be addressed in a future standard. EDITS: None SUBMITTED BY: HISTORY: 94-028 m128 additional items 8-9 -------------------------------------------------------------------------------- NUMBER: 000027 TITLE: Requirements for pointers and target association KEYWORDS: POINTER attribute, TARGET attribute, pointer association DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: If PTR has the POINTER attribute and TGT has the TARGET or POINTER attribute, under which of the following other conditions are PTR and TGT considered to be pointer associated, i.e., under which of the following conditions does ASSOCIATED(PTR, TGT) return a value of .TRUE.: a) PTR and TGT have different types? b) PTR and TGT have different type parameters? c) PTR and TGT have different ranks? d) PTR and TGT have different sizes? e) PTR and TGT have different shapes? f) PTR and TGT have different bounds? g) PTR and TGT refer to the same set of array elements/storage units, but not in the same array element order? h) PTR and TGT have array elements/storage units whose range of memory addresses overlap, but they have no identical array elements/storage units? i) PTR and TGT have at least one but not all identical array elements/storage units and all the identical elements have the same subscript order value in both PTR and TGT? j) PTR and TGT have at least one but not all identical array elements/storage units but not all the identical elements have the same subscript order value in both PTR and TGT? ANSWER: Any of the above conditions except for f) are sufficient for ASSOCIATED (PTR, TGT) to return a value of .FALSE.. In determining whether a pointer and a target are associated, the bounds are not relevant, but the extents are. The extents of each dimension of PTR and TGT must be the same, thus their shapes must match which is covered by condition (e). If TGT is zero sized, ASSOCIATED (PTR, TGT) returns .FALSE.. Discussion: There are only three means by which a pointer may become pointer associated: via the ALLOCATE statement (6.3.1), via pointer assignment (7.5.2), or via argument association (12.4.1.1). -- In an ALLOCATE statement, the object created inherits its type, type parameters, rank, shape, size and bounds from those declared for, or specified with, the pointer name. -- In a pointer assignment, the type, type parameters, and rank of the pointer and target must conform, and the shape, size, and order of elements of the target determine those of the pointer. -- When a pointer actual argument is passed to a pointer dummy argument, the pointer dummy argument becomes pointer associated with the same target as the pointer actual argument. In all three of these cases, array elements of the pointer and the target correspond with one another in array element order. Thus, since there is no other way for two objects to become pointer associated, their type, type parameters, rank, size, shape, and order of elements must be the same. REFERENCES: ISO/IEC 1539:1991 (E) 5.1.2.4.3, 6.3.1, 7.5.2, 12.4.1.1, & 14.6 EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-4 (120.022) HISTORY: 120-LJM-3A (120.081A) m121 Original response proposed 92-061 (121-ADT-9) p9 & X3J3/92-061 Questioned response (121-ADT-13) item 27 92-093A m121 Approved 92-329 (jw note) m123 Approval rescinded at m123 (uc) 93-099r1 m124 Revised response adopted (15-2) 93-111 m125 ballot failed, returned to subgroup 93-135r m125 Based on comments returned with the X3J3 letter ballot following m124, the revised response was prepared and adopted 15-3. 93-255r1 m127 ballot failed 17-7 94-289 m130 revised answer, approved u.c. 94-306 m131 X3J3 ballot failed 16-3 ------------------------------------------------------------------------------- NUMBER: 000028 TITLE: Host association and Implicit type rules KEYWORDS: use association, host association, implicit typing DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION 1: Consider the following program fragment: MODULE A CONTAINS SUBROUTINE B(Z) IMPLICIT INTEGER (X) 10 Z = XXX !Local variable or invalid function reference? ... END SUBROUTINE REAL FUNCTION XXX() ... END FUNCTION END MODULE In the above example in statement 10, is XXX an implicitly typed scalar variable or an erroneous function reference to module procedure XXX? That is to say, does the syntax of the reference determine which entity is referenced? QUESTION 2: Consider the following program fragment: MODULE X INTEGER, DIMENSION(10) :: A ... CONTAINS SUBROUTINE Y() ... CONTAINS SUBROUTINE Z(I) 20 A(I) = I ! Host associated array reference ! or invalid reference to function A? END SUBROUTINE FUNCTION A(K) ! Hides array A in module spec part? ... END FUNCTION END SUBROUTINE END MODULE Is the reference to A in statement 20 a reference to the array A declared in the module specification or an invalid reference to the internal procedure A? ANSWER 1: The reference to XXX is an invalid reference to the host associated module procedure XXX. The syntax of the reference does not determine which entity is referenced. ANSWER 2: The reference to A is an invalid reference to the host associated internal procedure A. Discussion: Section 5.3, in the fourth paragraph beginning "Any data entity ...", defines which data entities are implicitly typed. This definition excludes variables made accessible by use association or host association. In the first example, a form of reference does not differentiate between a host associated entity and a local implicitly typed scalar. In the second example, within subroutine Y the definition of the internal procedure A makes the array A inaccessible by host association (section 12.1.2.2.1). The internal procedure A is accessible within subroutine Z by host association. The reference to A(I) in subroutine Z is an invalid reference to function A. EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-6 (120.024)) HISTORY: 120-RL-3 (120.060) ui 105 ballot comments (jw note) 93-134 m125 unanimous consent 93-255r1 m127 ballot failed 23-1 93-329 m127 approved uc 94-034 m128 X3J3 ballot failed 26-2 94-106r1 m128 revised response, approved u.c 94-116 m129 X3J3 ballot failed 16-7 94-164 m129 clarify question and answer, approved u.c. 94-221 m130 X3J3 ballot approved 23-0 ------------------------------------------------------------------------------- NUMBER: 000030 TITLE: Length of character literals in array constructors KEYWORDS: array constructor, character DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Consider the following example: CHARACTER :: NAMES (3) * 20 NAMES = (/ 'TOM', 'DICK', 'HARRY' /) This appears to be invalid due to a constraint in section 4.5, "Construction of array values": Constraint: Each expression in the must have the same type and type parameters. The length of the string is a type parameter. Thus the array constructor sample above is invalid because the strings have different lengths. Consider another example: CALL SUB ( (/ 'TOM', 'DICK', 'HARRY' /) ) ... SUBROUTINE SUB (NAMES) CHARACTER :: NAMES(:) * (*) WRITE(*,*) LEN(NAMES) ... This also appears invalid. 1. Must each character string literal constant in an array constructor be the same length? 2. If the answer to 1 is "No", what values are printed by the second example? 3. If the answer to 1 is "Yes", another question arises. The syntax of an array constructor is described in section 4.5. In rule R432, is defined to be an or an . Since an may be an expression, a substring is a valid . Therefore each substring in an array constructor must have the same length and that length must be the same as the length of every other in the constructor. But a substring can contain nonconstant expressions as the starting point and ending point, or the starting point and ending point can be omitted (signaling the use of a default value). Since a substring can contain nonconstant starting and ending points, the constraint cited above cannot be detected at compile time and thus cannot be a constraint. Should this restriction be rephrased as prose in the text of the standard? ANSWER: The answer to question 1 is yes. Each character literal constant in an must be the same length. Both examples are nonstandard conforming. The answer to question 3 is yes. The following edits move the equal-length requirement from a constraint to prose in the text. Discussion: The awkwardness resulting from the requirement that each be the same length was noted by X3J3, but the committee could not reach agreement on an acceptable way to allow character literal constants of differing lengths in an . Since the length cannot always be determined at compile time, that part of the constraint must be changed to prose. EDITS: 1. In the second constraint following R435 [38:3-4] change: "the same type and type parameters." to: "the same type and kind type parameter." 2. Add the following paragraph after the constraints in 4.5. [38:4] If the expressions are of type character, each expression in the must have the same length type parameter. SUBMITTED BY: (Questions 1 and 2) Larry Rolison in 120-LRR-1 (120.026) (Question 3) Larry Rolison in X3J3/93-070 HISTORY: 120-LJO-1 (120.074) Response to Questions 1 and 2 - 93-070 m124 Question 3. submitted as 93-100 m124 proposed response, adopted by unanimous consent 93-111 m125 ballot approved with Rolison edit 94-160 m129 WG5 ballot, failed; 94-179 m129 minor edit changes 94-225r1 m130 adjust EDITS, as per WG5 ballot, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 -------------------------------------------------------------------------------- NUMBER: 000041 TITLE: Procedure with target dummy argument requires explicit interface KEYWORDS: argument - dummy, interface - explicit, TARGET attribute DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: If a procedure has a dummy argument that has the TARGET attribute, it must have an explicit interface (section 12.3.1.1). The TARGET attribute is defined solely for the purpose of aiding optimization (C.5.3). Why must such a procedure have an explicit interface? ANSWER: Section C.5.3 is in error by stating the TARGET attribute is solely to aid optimization. The supplied edit corrects the error. Discussion: Defect item 000125 supplies edits to make it clear that: If the dummy argument has the TARGET attribute and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure. (2) When execution of the procedure completes, any pointers associated with the dummy argument remain associated with the actual argument. In this case, the simple argument association mechanism that involves supplying only the location of the first storage unit of the argument or of a copy of the argument (see C.12.5) is not adequate at the point of reference. In particular, the location of the actual argument and details of its layout in storage may need to be available within the called routine to ensure that the pointer association works as described. EDIT: Section C.5.3, second sentence, change "solely" to "primarily". [269:21] SUBMITTED BY: K. Kazumura, X3J3/92-048 (121-ADT-8) page 23 HISTORY: Posted request to f90 interp e-mail ui 82, ui 111, ballot, 92-329 (jw note) 92-070 m121 Approved m123 Approval rescinded (uc) 93-101 m124 Revised response adopted by uc 93-111 m125 ballot approved m128 Status changed to "consideration in progress" as this refers to edits in 000121 that no longer exist 94-235 m130 draft revision, approved uc 94-306 m131 X3J3 ballot approved 18-1 -------------------------------------------------------------------------------- NUMBER: 000049 TITLE: Characteristics of function results KEYWORDS: characteristics, function result, ENTRY statement, exact dependence, association - partial, association - entry DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Given a character function with an ENTRY statement, both results must have the same characteristics or be scalars without the POINTER attribute and have identical length. Therefore: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN,ENT ... ENTRY ENT(M,N) ... END FUNCTION is standard conforming. Question 1: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=M+N)::ENT ... ENTRY ENT(M,N) ... END FUNCTION Is the code above standard conforming? Question 2: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=N+M)::ENT ... ENTRY ENT(M,N) ... END Is the code above standard conforming? Question 3: FUNCTION FUN(M) CHARACTER (LEN=M+M)::FUN CHARACTER (LEN=M*2)::ENT ... ENTRY ENT(M) ... END Is the code above standard conforming? Question 4: What is the meaning of the phrase "the exact dependence on the entities" in section 12.2.2? ANSWER: Answer 1. Yes Answer 2. Yes Answer 3. Yes Answer 4. The sentence containing the phrase "the exact dependence on the entities" in section 12.2.2 is intended to convey that in those cases where the shape or character length type parameter is not constant, the corresponding characteristic of the function result is not a value but the way the value is determined when the procedure is invoked. Discussion: Only the mapping from program state to value is significant, not the particular form in which that mapping is expressed. In question 3, for example, it is a characteristic of FUN and ENT that their lengths are twice the value of M. It is not required that the expressions of this mapping be identical, only that they yield the same results. Thus, twice the value of M could be expressed as M+M for FUN and as M*2 for ENT. The phrase "the exact dependence on the entities in the expression is a characteristic" is used to give the processor the freedom to evaluate lengths and bounds in any convenient manner. Since the characteristics must be the same, the phrase implies, as a minimum, that the expressions be algebraically equivalent and use the same variables. In an example such as: FUNCTION FUN(M) CHARACTER (LEN=M)::FUN CHARACTER (LEN=M + 0*K)::ENT ... ENTRY ENT(M, K) ... END FUN and ENT do not have the same characteristics since their dependence on "K" is different. Indeed, if on entry to FUN the length of FUN or ENT were evaluated using the expression for the length of ENT the evaluation would fail since K is not associated with a value. Clearly, it can be extremely difficult to determine on a static basis whether two expressions of a mapping are consistent, and there is no requirement in the standard that this be done. It would be possible to check during execution that the values expressed are identical each time such a procedure is invoked, but it is expected that a more typical application of this requirement would be to assume that it has been met and use one expression of this mapping as the basis for computing attributes of all of the result variables. REFERENCES: ISO/IEC 1539:1991 (E) section 12.2.2 & 14.6.3.3 EDITS: None SUBMITTED BY: Y. Yoshida, X3J3/92-051 (121-ADT-11) pp.-13 HISTORY: 92-109A m121 Approved 19-0 92-313 m123 response to ballot comments and approved by uc 93-105 Revised in response to ballot comments 93-152 m125 New edit, rejected 94-059 m128 New edit, 94-252 m130 New response without edits, approved u.c. 94-306 m131 X3J3 ballot approved 18-1 -------------------------------------------------------------------------------- NUMBER: 000054 TITLE: Resolving generic procedure references KEYWORDS: generic name, interface block, intrinsic procedure DEFECT TYPE: Interpretation STATUS: Hold for 000083, X3J3 approved; ready for WG5 QUESTION: Consider the following code fragment: PROGRAM HOST DIMENSION ABS(10) ... CONTAINS SUBROUTINE SUB() INTERFACE ABS FUNCTION IA1(I) INTEGER IA1, I END FUNCTION END INTERFACE R = ABS(1.5) Do the rules for resolving references to names established to be generic (14.1.2.4.1) imply that R will be assigned the value 1.5 as the result of invoking the intrinsic ABS? ANSWER: Yes. Discussion: ABS is established to be generic in the scope of subroutine SUB (14.1.2.4 item 1(a)). The rules in section 14.1.2.4.1 can be used to resolve the procedure reference. Rule (1) in 14.1.2.4.1 does not apply, as the reference is not consistent with any specific interface in the interface block with the name ABS. Rule (2) does not apply as ABS does not appear in an INTRINSIC statement. Rule (3) does not apply as ABS is not established to be generic in the host scope. Therefore, rule (4) is applied and the reference is resolved to the generic intrinsic procedure ABS. EDITS: None. SUBMITTED BY: Janice C. Shepherd HISTORY: 92-048 pg 29-30, 34-40, 51, 52, One of the questions raised in 92-052 pg 1-3 One of the questions raised in 92-119 Initially drafted 92-157 m122 approved m129 WG5 #550 email, J Martin, 94-04-26, failed WG5 ballot 94-293 m130 change status to HOLD for 000083 ------------------------------------------------------------------------------- NUMBER: 000058 TITLE: Ambiguous use of "keyword" KEYWORDS: keyword, argument keyword, statement keyword DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Is the use of "keyword" in 12.4.1, page 172, 1st paragraph consistent with the definition of "keyword" in 3.2.1, page 19? Is the definition of keyword in 3.2.1 consistent with the two definitions of keyword in 2.5.2, page 16? In 13.10, page 188, is "keyword" the correct term (or should it be "argument keyword")? ANSWER: The term "keyword" is used for both "statement keyword" and "argument keyword" - see 2.5.2 and Annex A. Which is intended is usually clear from the context, and this is so on pages 172 and 188. Section 3.2.1 is referring only to statement keywords and would be clearer if the qualifier "statement" is added. EDITS: Page 19 section 3.2.1 [19:37-38] Change "Keywords" to "Statement keywords" twice. Rationale: 3.2.1 is not referring to argument keywords. SUBMITTED BY: GEN HISTORY: WG5/N808, Question 2. 92-164A m122 approved 17-4 ballot comments, 92-326 (jw note) m124 minutes, approved 15-2 93-111 m125 ballot approved with Kelble edits 94-160 m129 WG5 ballot, failed; 94-361 m131 answer with fewer edits proposed, approved u.c. 95-034r1 m132 X3J3 ballot, approved 20-0 -------------------------------------------------------------------------------- NUMBER: 000070 TITLE: Characteristics specified by interface bodies KEYWORDS: characteristics, array bounds, array shape, function result DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 12.3.2.2 indicates that an interface body specifies all of a procedure's characteristics and that the characteristics must be consistent with those in the procedure definition. Are the following code fragments standard conforming? (a) PROGRAM FRED INTERFACE SUBROUTINE SUB (ARR,J) INTEGER ARR(1:) END SUBROUTINE END INTERFACE INTEGER ARR(10) CALL SUB(ARR,2) END PROGRAM SUBROUTINE SUB(ARR, J) INTEGER ARR(J:) ... END SUBROUTINE SUB (b) FUNCTION C1( ) CHARACTER(*) C1 ... END FUNCTION C1 FUNCTION C2(N) CHARACTER(N) C2 ... END FUNCTION C2 SUBROUTINE CALLER( ) INTERFACE FUNCTION C1( ) CHARACTER(*) C1 END FUNCTION FUNCTION C2(N) CHARACTER(2) C2 END FUNCTION END INTERFACE CHARACTER(5) CC CC=C1( )//C2(2) ANSWER: (a) This example is standard conforming. (b) This example is not standard conforming. Discussion: (a) 12.2.1.1 states that the characteristics of a dummy data object include its shape, and that if the shape is assumed then that is a characteristic. Section 2.4.5 states that the shape of an array is determined by its rank and extent in each dimension (but not by its bounds, 5.1.2.4.2). Both the interface block for SUB and the definition of SUB describe the shape of ARR as assumed, so they are describing the same shape, and the program is standard conforming. It is possible to read the second sentence in 12.2.1.1 as requiring bounds to match. This was not intended. An edit to that section (defect item 49) has clarified that it is the shape resulting from the bounds specifications that is a characteristic and not the bounds themselves. (b) Section 12.2.2 states that the characteristics of a function include whether or not the function result value is a character of assumed length. So the interface body for function C1 must indicate that C1 is of assumed length. However, item (3) in 5.1.1.5 indicates that scoping units that invoke an external character function of assumed length must have access to a declaration of the function name with a length type parameter value other than *. An edit is included to clarify this restriction. In addition, the interface for C2 does not conform to the standard as the length of C2 specified as 2 is not consistent with the length specified as N within the function definition. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.4.5, 5.1.1.5, 5.1.2.4.2, 12.2.1.1, and 12.2.2. EDITS: In section 5.1.1.5 item (3), add to the end [43:5]: "Note that the interface for such a function cannot be specified in an interface body." SUBMITTED BY: Graham Barber (a), Janice Shepherd (b) HISTORY: 92-264 Question (a) originally posed 92-46 Question (b) originally posed in e-mail collection ui 48 (jw note) 92-283 Response proposed m123 Approved by unanimous consent 93-018 Response questioned by John Reid in 93-103 Revised response proposed m124 Approved by unanimous consent 93-111 m125 ballot, return to subgroup, Leonard comment, coordinate with 0000049? 94-060 m128 New edit in 0000049 referenced ------------------------------------------------------------------------------- NUMBER: 000081 TITLE: Pointer actual argument overlap KEYWORDS: pointer, target, argument - actual, argument - dummy, argument association DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 12.5.2.9, Restrictions on entities associated with dummy arguments, clearly states that if there is partial or complete overlap between actual arguments associated with two different dummy arguments of the same procedure, the overlapping portions may not be defined, redefined, or undefined during the procedure execution. It continues: This restriction applies equally to pointer targets. For example, in REAL, DIMENSION (10), TARGET :: A REAL, DIMENSION (:), POINTER :: B, C B => A (1:5) C => A (3:9) CALL SUB (B, C) B (3:5) cannot be defined because it is part of the actual argument associated with the second dummy argument. C (1:3) cannot be defined because it is part of the argument associated with the first dummy argument. A (1:2) [which is B (1:2)] remains definable through the first dummy argument and A (6:9) [which is C (4:7)] remains definable through the second dummy argument. Unfortunately, this example does not contain an explicit interface for the called subroutine, nor are there sufficient words to clearly state what is meant by the words and example provided. Question 1: Do the above restrictions hold when both dummy arguments are nonpointers? In this case the following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y END SUBROUTINE END INTERFACE Question 2: Same as question 1, only add the TARGET attribute to one or both of the dummy arguments. The following interfaces may describe SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:), TARGET :: X, Y END SUBROUTINE END INTERFACE or INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y TARGET X END SUBROUTINE END INTERFACE Question 3: Do the above restrictions hold *upon entry* when both dummy arguments are pointers? That is, *upon entry* to SUB, is it safe to assume that pointer dummy arguments do not have overlapping elements which may get defined during execution of SUB? The following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:), POINTER :: X, Y END SUBROUTINE END INTERFACE Question 4: Same as question 3, but one dummy argument is a pointer, one has the target attribute? *Upon entry* to SUB, is it safe to assume a pointer dummy argument does not point to any elements of a target dummy argument which may get defined during execution of SUB, but during the execution of SUB such an association may come to exist? The following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y POINTER X TARGET Y END SUBROUTINE END INTERFACE Question 5: Two derived type dummy arguments each have a subobject (or a subobject of a subobject etc.) which are pointers with the same type, kind type parameter, and rank. *Upon entry* to the subroutine, is it safe to assume such pointer subobjects do not have overlapping targets which may get defined? That is, in the following fragment, *upon entry* to SUB, is it safe to assume X%PTR_1 and Y%PTR_2 cannot have overlapping target elements which get defined during execution of SUB? SUBROUTINE SUB (X, Y) TYPE A SEQUENCE REAL, DIMENSION(:), POINTER :: PTR_1 END TYPE TYPE B SEQUENCE REAL, DIMENSION(:), POINTER :: PTR_2 END TYPE TYPE (A) :: X TYPE (B) :: Y ANSWER: There is a deficiency in the standard. The restrictions always apply to the allocation status or pointer association status of the entities, but do not apply to the values when (1) the dummy argument or a subobject of the dummy argument has the POINTER attribute or (2) the dummy argument has the TARGET attribute and does not have INTENT(IN) and the actual argument is a target other than an array section with a vector subscript. Edits are supplied to correct this. The answers to the specific questions are: Answer 1: Yes for the interface specified. Answer 2: Yes for the allocation status or pointer association status of the entities. Yes for the values except when (2) holds. Answer 3: Yes for the allocation status or pointer association status of the entities. No for the values. Overlapping elements of dummy arguments may be defined during execution of SUB. Answer 4 (first part): Yes for the allocation status or pointer association status of the entities. No for the value of the pointer argument. No for the value of the target argument when it is not of INTENT(IN) and the actual argument is a target other than an array section with a vector subscript. Yes for the value of the target argument in other cases. Answer 4 (second part): Upon entry to SUB, a pointer dummy argument may point to an element of a target dummy argument that is defined during execution of SUB. Answer 5: Yes for the allocation status or pointer association status of the entities. No for the values. Overlapping elements of pointer components of dummy arguments may be defined during execution of SUB. Discussion: The restrictions of Section 12.5.2.9 on entities associated with dummy arguments are intended to allow a variety of optimizations in the translation of the procedure, including implementations of argument association in which the value of an actual argument that is neither a pointer nor a target is maintained in a register or in local storage. The latter mechanism is usually known as "copy-in/copy-out". The text assumed that the rules applied to an actual argument with the TARGET attribute, too, but defect item 125 has made it clear that this is not the case and edits are needed in 12.5.2.9. The present text is correct with respect to the "availability" of an entity associated with a dummy argument. Neither pointer assignment nor any of the statements ALLOCATE, DEALLOCATE, NULLIFY may be applied other than through the dummy argument. For example, in the code INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGP) INTEGER, POINTER :: IARGP INTEGER, TARGET :: J IP => J ! Illegal the pointer assignment is not allowed because it is changing the pointer association of the actual argument. In the case of a dummy argument with the attribute POINTER or TARGET, the implementation can assume that its descriptor is distinct from any other entity accessible in the procedure. The present text is incorrect for the value of a pointer dummy argument. Here, the implementation must allow for the value to be altered through another pointer as in the example INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGP) INTEGER, POINTER :: IARGP INTEGER, TARGET :: J IP = 0 ! OK. This alters the value of IARGP, too. It is also incorrect where the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), and the actual argument is a target other than an array section with a vector subscript. Here the implementation must allow for the value to be altered through a pointer as in the example INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGT) INTEGER, TARGET :: IARGT IP = 0 ! OK. This alters the value of IARGT, too. EDITS: 1. In section 12.5.2.9, [180:3-4] Replace the first two lines of item (1) by "Action that affects the pointer association status of the entity or any part of it (any pointer assignment, allocation, deallocation, or nullification) must be taken through the dummy argument. No action that affects the allocation status of the entity may be taken. Action that affects the value of the entity or any part of it must be taken through the dummy argument unless (a) the dummy argument has the POINTER attribute, (b) the part is all or part of a pointer subobject, or (c) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), and the actual argument is a target other than an array section with a vector subscript. For example, in" 2. In section 12.5.2.9, [180:32] in the line following the line "DEALLOCATE (A)" change 'availability' to 'pointer association status'. 3. In section 12.5.2.9, [180:37] in the second to last paragraph on page 180, after "the same procedure" add "and the dummy arguments have neither the POINTER nor the TARGET attribute". 4. In section 12.5.2.9, [181:8] in line 8 of page 181, after "CALL SUB(B,C)" add "! The dummy arguments of SUB are neither pointers nor targets". 5. In section 12.5.2.9, [181:17-19] Replace the first three lines of item (2) by "If the pointer association status of any part of the entity is affected through the dummy argument, then at any time during the execution of the procedure, either before or after the definition, it may be referenced only through that dummy argument. If the value of any part of the entity is affected through the dummy argument, then at any time during the execution of the procedure, either before or after the definition, it may be referenced only through that dummy argument unless (a) the dummy argument has the POINTER attribute, (b) the part is all or part of a pointer subobject, or (c) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), and the actual argument is a target other than an array section with a vector subscript. For example, in" 6. In section C.12.7, [291:40-42] Replace lines 3 to 5 by "The restrictions on entities associated with dummy arguments are intended to allow a variety of optimizations in the translation of the procedure, including implementations of argument association in which the value of an actual argument that is neither a pointer nor a target is maintained in a register or in local storage." ' SUBMITTED BY: Jon Steidel HISTORY: 92-208 m123 Submitted 93-85 m124 Proposed response, withdrawn 93-174 m125 Revised response, withdrawn 93-213 m126 Revised response, adopted by unanimous consent 93-255r1 m127 ballot failed 19-5 94-248 m130 Revised response and edits. 94-282r1 m130 Clarified terminology, approved u.c. 94-306 m131 ballot failed 11-7 94-309r1 m131 modified edits and answer, approved 12-1 94-366r1 m131 First edit replaced with revised text from 94-366r1 approved u.c. 95-034r1 m132 X3J3 ballot failed, 16-4 -------------------------------------------------------------------------------- NUMBER: 000083 TITLE: Extending generic intrinsic procedures KEYWORDS: generic name, intrinsic procedure, interface block, INTRINSIC attribute DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Is the following code fragment standard conforming? INTERFACE SIN REAL FUNCTION MY_SIN(X) REAL, INTENT(IN) :: X END FUNCTION END INTERFACE Section 14.1.2.3 contains the following sentence: "When an intrinsic procedure, operator, or assignment is extended, the rules apply as if the intrinsic consisted of a collection of specific procedures, one for each allowed combination of type, kind type parameter, and rank for each argument or operand." This sentence indicates that there is a "hidden" generic interface for the intrinsic SIN that looks something like : INTERFACE SIN REAL FUNCTION DEFAULT_REAL_SIN(X) REAL, INTENT(IN) :: X END FUNCTION REAL FUNCTION REAL_DIFFERENT_KIND_SIN(X) REAL(KIND=), INTENT(IN) :: X END FUNCTION ... COMPLEX FUNCTION CSIN(X) COMPLEX, INTENT(IN) :: X END FUNCTION ... END INTERFACE Section 11.3.2 indicates that if a user supplies a generic interface SIN such as in the first example, the user interface will be treated as a single interface with the "hidden" generic intrinsic interface. However, according to the rules of section 14.1.2.3 the MY_SIN specific interface and the "hidden" DEFAULT_REAL_SIN specific interface are ambiguous. Therefore users must not write generic interfaces unless they are sure that the generic name they select and the arguments to the specific interfaces they specify will not conflict with any "hidden" generic interfaces implied by the generic intrinsics. ANSWER: The code fragment ought to be standard conforming. Edits are provided to reflect this. Discussion: As the standard is currently written, if a generic interface were written an ambiguity as described in the rules of 14.1.2.3 could not be avoided without knowledge of all intrinsics. Requiring such knowledge is a severe hindrance to the useability of generic interfaces. An edit is supplied so that the rules in 14.1.2.3 do not apply to the specific procedures represented by a generic intrinsic. The rules for resolving procedure references to names established to be generic are given in section 14.1.2.4.1. Section 12.3.2.3 describes the semantics of the INTRINSIC statement. An edit is supplied for this section to clarify that the name of a generic intrinsic function with the INTRINSIC attribute can also be the name of a generic interface. EDITS: 1. In section 12.3.2.3 add to the end of the first paragraph after the constraint [171:12]: "The appearance of a generic intrinsic procedure name in an INTRINSIC statement does not mean that the name cannot also appear as the name of a generic interface (14.1.2.3)." 2. In section 14.1.2.3 in the third sentence [242:28]: change "When an intrinsic procedure, operator, or" to "When an intrinsic operator or" SUBMITTED BY: Larry Rolison HISTORY: 92-210 m123 submitted 93-180 m125 Response, approved 19-1 93-255r1 m127 ballot failed 21-3 94-163r1 m129 Clarified answer and added another edit. withdrawn as new edit needs rewording. 94-241 m130 Sorted edits. Revised edit 1. Add edit 3. 94-290r1 m130 Revised edit 2 and deleted edit 3. Simplified discussion. Approved u.c. 94-306 m131 X3J3 ballot failed 12-7 -------------------------------------------------------------------------------- NUMBER: 000086 TITLE: USE and host association KEYWORDS: use association, host association, generic interface, EXTERNAL statement DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Use association, 11.3.2 states The USE statement provides the means by which a scoping unit accesses named data objects, derived types, interface blocks, procedures, generic identifiers (12.3.2.1), and namelist groups in a module. Host association, 12.1.2.2.1 states An internal subprogram, a module subprogram, or a derived-type definition has access to the named entities from its host via host association. The accessed entities are known by the same name and have the same attributes as in the host and are variables, constants, procedures including interfaces, derived types, type parameters, derived-type components, and namelist groups. Question 1: Do use and host association access the same entities? What entities does each access? Question 2: For both use and host association, what entities are not accessed? Question 3: For host and use association, if the host or module referenced contains an EXTERNAL statement for ABC, is ABC an accessed entity that has the EXTERNAL attribute? Note that an EXTERNAL statement is not a "named entity" (the statement has no name) and the procedure named in the statement is not in the host or module (that is the reason for the EXTERNAL statement). The answer to question 1 or 2 should also answer this question. Question 4: Given the following PROGRAM A MODULE M USE X USE Y CONTAINS SUBROUTINE B USE M is subprogram B associated in some way with X? What way? Note that A, the host of B, "accesses" entities in X by use association; the entities in X are not "in" B's host. Question 5: In the same example, is subprogram B associated in some way with Y? What way? As with question 4 note that the entities in Y are "accessed" from M; the entities in Y are not in M and use association refers to the entities "in the module". Question 6: Given the following: MODULE A ! level 1 host USE AA INTERFACE F ... CONTAINS SUBROUTINE B ! module subroutine, level 2 host USE BB INTERFACE F .... CONTAINS SUBROUTINE C ! internal subprogram USE CC INTERFACE F ... .... = F(X) ! an invocation of the generic name F and where modules AA, BB, and CC all contain a generic interface for F: How is the invocation of the generic name F resolved? (in what sequence are the host scopes and the modules used considered?) Note the levels of nesting: A contains B contains C. Section 14.1.2.4.1, "Resolving procedure references to names established to be generic", (3), seems to consider only B, the host of C, and not A. ANSWER: Answer 1: Entities declared PRIVATE are potentially accessible by host association but not by use association. Otherwise, it was intended that the classes of entities made accessible by these two forms of association be the same. These are named data objects (including both constants and variables), derived types, derived type components, procedures (both those defined in the host or module and those declared there and defined elsewhere; both those identified by names and those identified by other generic identifiers), and namelist groups. See sections 12.1.2.2.1 and 11.3.2. While the words used to describe the classes of accessible entities are not identical the meaning behind the words is the same. Future versions of the standard should endeavor to use the same words for these two lists. Answer 2: Entities not in the list in 12.1.2.2.1 and 11.3.2 are not made accessible. For example, FORMAT statement labels, construct names, and common block names are not made accessible. Answer 3: In such an example, ABC would be accessible. Section 12.3.2.2 indicates that the EXTERNAL statement specifies a list of names that are procedures. In the host or module, ABC is the name of a procedure and thus is the name of a potentially accessible entity; it is not necessary that the definition of ABC be present in the host or module. Answer 4: The entities of module X made accessible in A by use association are made accessible in B by host association. Note that each such entity has a local name (or other identifier) in A. See Section 11.3.2. Answer 5: The entities of module Y made accessible in M by use association are made accessible in B by use association. Note that each such entity has a local name (or other identifier) in M. See Section 11.3.2. Answer 6: In effect, first C and CC are checked for a consistent specific interface, then B and BB, then A and AA, and finally (if F were the generic name of an intrinsic function) the intrinsics are checked. In applying 14.1.2.4.1 to a reference in C, item (1) provides the check of interfaces in C (including those made accessible from CC), and item (3) provides for a recursive application of 14.1.2.4.1 to B. In this recursive application, (1) checks B (and BB), and (3) results in a further recursive application of 14.1.2.4.1 to A. In this application, (1) checks A (and AA), (3) is not applicable, and (4) checks the intrinsics. 14.1.2.3 establishes that there must be no ambiguity in distinguishing the interfaces declared in C from those made accessible from CC. EDITS: None. SUBMITTED BY: Dick Weaver HISTORY: 92-214 Submitted 92-281 m123 Response proposed (11-7 was insufficient for approval) 93-030r1 Revised response proposed m124 Approved (15-1) 93-111 m125 ballot approved with Kelble, Leonard, Martin, Rolison edits 93-234 m126 edit replaced by that in item 82, approved uc Note: cannot go forward until 000082 does. 94-034 m128 Relying on edit in 000082 that has been removed, status changed to X3J3 consideration in progress 94-240r1 m130 Revised response with no edit, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 -------------------------------------------------------------------------------- NUMBER: 000090 TITLE: Subroutine and function names in nested scopes KEYWORDS: procedure names, nested scopes, internal procedures, names - class, derived type DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 12.1.2.2.1 indicates A name that appears in the scoping unit as (2) a in a ... (3) a in a ... is the name of a local entity and any entity of the host that has this as its nongeneric name is inaccessible. Entities that are local (14.1.2) to a procedure are not accessible to its host. 1. If this is true, how can hosts reference internal procedures, module procedures and interface blocks (the text in 2.2.3.3 pertains only to internal procedures and is somewhat vague) ? 2. Are entities local to an interface body accessible to the host? (i.e., should the "Entities that are local ..." rule above be more general?) ANSWER: 1. The text cited from sections 12.1.2.2.1 and 14.1.2 contains errors. The text in 12.1.2.2.1 was intended to describe how names established to be: a) A derived type name in the scope of an internal subprogram or in the scope of a module subprogram; b) an internal subprogram in the scope of a module subprogram; c) a procedure name by its appearance in an interface body in the scope of an internal subprogram or in the scope of a module subprogram; makes inaccessible any entity of the host of the specified scope that has the name as its nongeneric name. Edits are provided to clarify this intent. Derived-type statements, SUBROUTINE statements and FUNCTION statements establish a new scope, but the derived-type name, subroutine name and function name defined by those statements are local entities of the host scope. Additional rules are then needed to prevent the name of a module procedure, internal procedure, procedure specified in an interface body, or derived type from conflicting with the names of local and global entities within the scope. These rules are included in the edits below. 2. No, entities local to an interface body are not accessible to the host. This is part of the more general rule stated in the first two paragraphs of section 14. "Entities are identified by lexical tokens within a scope..." "By means of association, an entity may be referred to... in a different scoping unit..." Thus, in the absence of association, an entity is not accessible in different scoping units. The statement in section 12.1.2.2.1 that "Entities that are local (14.1.2) to a procedure are not accessible to its host." is there to explain two things: a) Host association allows entities of a host to be accessed in a procedure but entities that are local to a procedure are not accessible to its host. b) Host association applies to derived-type definitions. Component names local to those derived-type definitions are accessible in the host scope. EDITS: 1. In section 12.1.2.2.1: [163:39] change: "A name that appears in the scoping unit as an in an " to: "A name that is declared to be an external procedure name (by an or an ), or that appears as a in a " 2. In the list specified in section 12.1.2.2.1: [164:3-7] Delete items (1), (3) and (4) and renumber the rest. 3. In the list specified in section 12.1.2.2.1: [164:4] change: "A in a , in a , or" to: "A in a or" 4. In section 12.1.2.2.1 ahead of the sentence "Entities that are local (14.1.2) to a procedure are not accessible to its host." add: [164:22] "If a scoping unit contains a subprogram or a derived type definition, the name of the subprogram or derived type is the name of a local entity. Any entity of the host of this scoping unit that has a nongeneric name that is the same as the name of the subprogram or derived type is inaccessible." 5. At the end of the last sentence of section 14.1.2 add: [242:13] "except in the following cases: (1) The name that appears as a in a has limited use within the scope established by the . It can be used to identify recursive references of the subroutine or to identify the name of a common block (the latter is possible only for internal and module subroutines). (2) The name that appears as a in a has limited use within the scope established by that . It can be used to identify the result variable, to identify recursive references of the function, or to identify the name of a common block (this last use is possible only for internal and module functions). (3) The name that appears as an in an has limited use within the scope of the subprogram in which the appears. It can be used to identify the name of a common block (if the ENTRY statement is in a module subprogram), to identify recursive references, or if the subprogram is a function to identify the result variable." SUBMITTED BY: Dick Weaver, X3J3/92-220 HISTORY: 92-220 submitted 92-328 m123 first draft response in (failed) 93-107 Alternate proposal submitted m124 Action deferred because of short lead time. m125 edits per Kelble notes! m125 minutes, page 13, approved uc 93-234 m126 most edits replaced by item 82, approved uc 93-255r1 m127 ballot passed 24-0 93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot failed 25-2 94-332r1 m131 edits based on 93-107, approved u.c. 95-034r1 m132 X3J3 ballot approved, 20-0 -------------------------------------------------------------------------------- NUMBER: 000091 TITLE: Constraint diagnosis for PRIVATE attribute KEYWORDS: PRIVATE attribute, module, conformance DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress *************************************************** * * * NOT CURRENT * * * * ----------- SEE 93-220 * * * *************************************************** QUESTION: Must the violation of constraints be diagnosed when the criteria for the constraint is violated or confirmed across module definitions? More specifically should the following two constraints: The third constraint following R522: [49:26-28] A module procedure that has a dummy argument or function result of a type that has PRIVATE accessibility must have PRIVATE accessibility and must not have a generic identifier that has PUBLIC accessibility. The fourth constraint following R424: [33:10-11] If a component of a derived type is of a type declared to be private, either the derived type definition must contain the PRIVATE statement or the derived type must be private. be diagnosed in the following program?: MODULE A TYPE X INTEGER :: I END TYPE X TYPE Y TYPE (X) :: R ! Note component of type X END TYPE Y CONTAINS FUNCTION F() ! Module function of type X TYPE(X) :: F END FUNCTION F END MODULE A MODULE B USE A PRIVATE :: X ! Note component of type Y now has ! a PRIVATE attribute ! Note also that module function F now ! has PRIVATE attribute END MODULE B ANSWER: There are no constraints that apply across module definitions. The specific constraints cited are not violated in the example program containing module A and module B. Note that the comments in module B in the example program are incorrect. Discussion: With regard to the example above, the accessibility attributes (PUBLIC and PRIVATE) apply to a type name, not the type itself. For example, the following is allowed: MODULE C USE A, X1 => X, X2 => X PRIVATE :: X1 PUBLIC :: X2 ... END MODULE C Conformance is based only on the accessibility of a type in the module in which the type is defined. Y and F are defined in module A where the type X is public. If a type with a component X were defined in module B, it would have to be a private type or contain the PRIVATE statement. REFERENCES: ISO/IEC 1539:1991 (E) sections 1.4, 4.4.1, and 5.2.3 EDITS: None. SUBMITTED BY: Maureen Hoffert HISTORY: 92-225 m123 Submitted 93-024 m124 Response adopted (14-3). 93-111 m125 ballot, return to subgroup based on Hirchert comment Consider restricting constraints to "within a scoping unit" 93-137r m125 Based on comments returned with the X3J3 letter ballot following m124, the revised response, containing the opposite answer, was prepared, passed, and then withdrawn (see 93-177) 93-177 an alternate response (see 93-137) 93-220 m126 withdrawn -------------------------------------------------------------------------------- NUMBER: 000096 TITLE: Definition of "Declaration" KEYWORDS: declaration, specification DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: "Declaration" is a significant concept of Fortran 90. Section 5 is titled "Data object declarations and specifications" and what were in FORTRAN 77 "type statements" are now "type declaration statements". 5.1.1 states "A type specifier specifies the type of all entities declared in an entity declaration list." Nowhere, though, is there a definition of "declaration". What does it mean, in Fortran 90, to "declare" something? ANSWER: The edits below add a definition of "declaration" and, for clarity, also add a definition of "specification". Edits related to these definitions are also provided. REFERENCES: EDITS: 1. Replace the text of 2.5.3 "Declaration" [16:13-18] with: A data object declaration specifies the creation, attributes, and lifetime of the object. Every data object must be declared. Declarations can be explicit or contextual. Data object attributes not specified explicitly are determined implicitly. A declaration of a data object of derived type is also a declaration of all of its components. In a scoping unit, if a name appears as: (1) an object-name in an entity-decl in a type-declaration, SAVE, POINTER, or TARGET stmt (2) a named-constant in a named-constant-def in a PARAMETER statement (3) an array-name in a DIMENSION or ALLOCATABLE statement (4) a variable-name in a common-block-object in a COMMON statement (5) the name of a variable that is wholly or partially initialized in a DATA statement (6) the name of an object that is wholly or partially equivalenced in an EQUIVALENCE statement (7) a dummy-arg-name in a FUNCTION, SUBROUTINE, ENTRY or statement-function statement (8) a result-name in a FUNCTION or ENTRY statement then those statements constitute an explicit declaration of a data object with that name in that scoping unit. otherwise: if a name that is not a procedure name, module name, program name, generic identifier, common block name, namelist group name, construct name, or derived type name, appears in any statement and that name is not the name of a data object accessed by host or use association then those appearances constitute a contextual declaration of a data object with that name in that scoping unit 2. In section 5.2.9 "DATA statement", in the fifth constraint following R537 [52:31-32]: delete "made accessible by use or host association," as now redundant with the definitions of use and host association. 3. In 11.3.2 "USE statement", in the paragraph beginning "If two or more" in the third sentence [158:29-31]: change: through to: through explicit declaration, 4. In 12.1.2.2.1 "Host association" replace items 5 though 12 with the one new item [164:8-17] (5) An explicitly declared data object (2.5.3); 5. In Annex A, add to page 256 after "datum" [256:10+] Declaration(2.5.3): A declaration specifies the existence of a data object. 6. In Annex A, add to page 260 after "size" [260:14+] Specification: A specification assigns attributes and properties to names. SUBMITTED BY: Dick Weaver HISTORY: 92-232 Submitted 92-232r Draft response, withdrawn 93-144 m125 unanimous consent 93-255r1 m127 ballot failed 16-7 94-103 m128 revised response, approved uc 94-116 m129 X3J3 ballot failed 16-7 94-223 m130 revised response --------------------------------------------------------------------------------