PC file: 95-006a4.0 Archive: 95-006r4.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 that the reasons for failing them can be recorded for historical purposes. No further voting is needed for items in this list. 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: 000049 TITLE: Characteristics of function results KEYWORDS: characteristics, function result, ENTRY statement, exact dependence, association - partial, association - entry DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress 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 95-044 m132 WG5 ballot failed, text in Answer 4 and discussion needs revision -------------------------------------------------------------------------------- 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 HOLD for 83 ------------------------------------------------------------------------------- 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, is a scalar or an assumed-shape array and does not have the INTENT(IN) attribute 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 INTENT(IN), it is scalar or an assumed-shape array 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 assumed-shape 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 facilitate 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 for all actual arguments with the TARGET attribute 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), the dummy argument is a scalar object or an assumed-shape array 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), the dummy argument is a scalar object or an assumed-shape array 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), the dummy argument is a scalar object or an assumed-shape array 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 facilitate 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 95-043 m132 revised words of answer/edit (no change in intent) and change status to X3J3 approved; approved 10-4 95-244 m134 Updated answer and edits based on new answer to defect item 125, approved u.c. 95-256 m135 X3J3 ballot failed, 10-6 ------------------------------------------------------------------------------ NUMBER: 000083 TITLE: Extending generic intrinsic procedures KEYWORDS: generic name, intrinsic procedure, interface block, INTRINSIC attribute DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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 procedure 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]: "In a scoping unit a name can appear as both the name of a generic intrinsic procedure in an INTRINSIC statement and as the name of a generic interface if procedures in the interface and the specific intrinsic procedures are all functions or all subroutines (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" 3. In section 14.1.2.3 add as a new paragraph at the end of the section [243:13+] "If a generic name is the same as the name of a generic intrinsic procedure, the generic intrinsic procedure is not accessible if the procedures in the interface and the intrinsic procedure are not all functions or not all subroutines. If a generic invocation applies to both a specific procedure from an interface and an accessible generic intrinsic procedure, it is the specific procedure from the interface that is referenced." 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 95-196 m134 new version of edits, approved 13-2 95-256 m135 X3J3 ballot, approved 15-1 -------------------------------------------------------------------------------- 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, modules, constraints DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Must the violation of constraints be diagnosed when the criteria for the constraint are 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 ! Does the type Y now have a PRIVATE component? ! Does the function F now have a PRIVATE type? END MODULE B ANSWER: Yes, the violation of a constraint must be diagnosed when the criteria for the constraint are violated across module definitions. For example: MODULE C INTEGER :: I END MODULE C MODULE D USE C, X=>Y END MODULE D In section 11.3.2, "Use Association", the second constraint requires that the Y in module D be a public entity of module C. This example violates this constraint and diagnosis is required. However, the sample code in the question is standard conforming; thus no diagnostic is required. The constraints cited in the question do not apply because the type X is not declared to be private in the module A, where X is defined. The type X is public. The "PRIVATE :: X" statement in module B does not change the public nature of the type X as defined in module A. The type X is not a public entity of module B, but it is still a public entity of module A. Therefore, the type Y does not have a private component and the function F does not have a private type. Defect item 161 discusses this issue in more detail and provides relevant citations. 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 95-015r1 m132 revised response references interp 161. Note that this should not proceed to the next STATUS level, unless 161 is also at that level. 95-101 m133 X3J3 ballot approved, 17-1, with edits applied -------------------------------------------------------------------------------- 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 statement (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 94-335 m131 alternate response proposed, withdrawn --------------------------------------------------------------------------------