From jwagener@amoco.com Thu Feb 25 09:14:45 1993 Received: from interlock.amoco.com by dkuug.dk with SMTP id AA17462 (5.65c8/IDA-1.4.4j for ); Thu, 25 Feb 1993 22:15:06 +0100 Received: by interlock.amoco.com id AA20356 (InterLock SMTP Gateway 1.1 for SC22WG5@dkuug.dk); Thu, 25 Feb 1993 15:07:53 -0600 Received: by interlock.amoco.com (Internal Mail Agent-2); Thu, 25 Feb 1993 15:07:53 -0600 Received: by interlock.amoco.com (Internal Mail Agent-1); Thu, 25 Feb 1993 15:07:53 -0600 Date: Thu, 25 Feb 93 15:14:45 CST Message-Id: <9302252114.AA10779@trc.amoco.com> From: Jerrold L. Wagener To: SC22WG5@dkuug.dk Subject: X3J3/93-006r ballot, part 2 of 2 X-Charset: ASCII X-Char-Esc: 29 NUMBER: 000082 TITLE: Host association and generic names KEYWORDS: host association, generic names, accessibility DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Consider the program fragment 1 INTERFACE F 2 FUNCTION X(Y) ... 3 CONTAINS ... 4 INTEGER F(10) 5 I = F(2) Reading in 12.1.2.2.1, Host association: Statement 4 defines F to be an object-name (item 5 in the list on page 164). Thus F is the name of a local entity and any entity of the host that has F as its nongeneric name is inaccessible (text following list on page 164). Therefore the generic name, F, in the host is accessible. With that, is F(2) in statement 5 a reference to the generic name or to the array name? ANSWER: F(2) is a reference to the array name. Discussion: The rules in 12.1.2.2.1 are incomplete as they fail to address the case of a generic name in the host. An edit is included to supply the missing rules. Applied to this case, they indicate that the outer F is inaccessible because the inner F is nongeneric. REFERENCES: ISO/IEC 1539:1991 (E) sections 12.1.2.2.1, 14.1.2.3, and 14.1.2.4 EDIT: In 12.1.2.2.1, insert the following after the sentence containing the long numbered list: If the local entity is nongeneric, any entity of the host that has this name as its generic name is inaccessible. If the local entity is generic and an entity of the host has this name as its generic name, the versions of the host entity that are prohibited by 14.1.2.3 from being merged with the local entity are instead inaccessible. SUBMITTED BY: Richard Weaver LAST SIGNIFICANT CHANGE: 93 02 11, initial response 000082 HISTORY: Submitted as X3J3/92-235 Related question submitted in X3J3/92-209 Response proposed in X3J3/92-104. Approved by unanimous consent at meeting 124. -------------------------------------------------------------------------- NUMBER: 000086 TITLE: USE and Host Association KEYWORDS: Use, association, host, accumulating, generic interface, EXTERNAL DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Use association, 11.3.2 states The USE statement provides the means by which a scoping unit access 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 why 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 is 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 which hosts and uses 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.1 and 11.3.2. An edit is provided to make the cited text consistent. Answer 2: Entities not in the list in 12.1.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 potentially an 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. REFERENCES: ISO/IEC 1539:1991 (E) sections 11.3.2, 12.1.2.2.1, 14.1.2.3, and 14.1.2.4.1. EDIT: In section 12.1.2.2.1 replace the second sentence of the first paragraph with: The accessed entities are known by the same name and have the same attributes as in the host and are named data objects, derived types, derived type components, interface blocks, procedures, generic identifiers (12.3.2.1), and namelist groups. SUBMITTED BY: Richard Weaver LAST SIGNIFICANT CHANGE: 1992-11-10, new 000086 HISTORY: Submitted in X3J3/92-214 Response proposed in 92-281 - meeting 123 (vote of 11-7 was insufficient for approval) Revised response proposed in 93-030r1. Approved at meeting 124 by a vote of (15-1) -------------------------------------------------------------------------- NUMBER: 000087 TITLE: PARAMETER statements and SAVE statements KEYWORDS: PARAMETER, named constant, SAVE DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Can a named constant appear in a SAVE statement? In Fortran 77 named constants were not allowed to appear in a SAVE statement. Fortran 90 appears to allow named constants in SAVE statements. ANSWER: No, a named constant must not appear in a SAVE statement. Edits are provided to indicate this restriction. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1, 5.1.2.5 EDITS: 1. Change the sixteenth constraint of section 5.1 to The SAVE attribute must not be specified for an object that is in a common block, a dummy argument, a procedure, a function result, an automatic data object, or an object with the PARAMETER attribute. 2. Change the penultimate sentence of 5.1.2.5 from "The SAVE attribute ... result, or an automatic data object." to "The SAVE attribute ... result, an automatic data object, or an object with the PARAMETER attribute." SUBMITTED BY: Janice C. Shepherd 93-011 LAST SIGNIFICANT CHANGE: 1993-02-10 000087 HISTORY: Submitted as 93-011 with proposed response After minor edits, adopted by unanimous consent at meeting 124 -------------------------------------------------------------------------- NUMBER: 000089 TITLE: Errors in the DATA statement description KEYWORDS: DATA statement, structure constructor, named constant, constant DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Does the text description in section 5.2.9 [53:4-20] of the values permitted in a DATA statement contain a recurring flaw? This description continually refers to the constant values in the list as simply "constants". According to R533 a structure constructor is allowed in the list, but it is not a constant; rather it is a constant expression. This is demonstrated by: The definition of "constant" in 2.4.3.1.2. There are only two broad categories of constants defined: named constants and literal constants. The syntax rules for "constant" (R305-R307) reinforce this definition by defining only two nonterminals: literal-constant and named-constant. The description of the structure constructor in section 4.4.4 [37:10-11] states: A structure constructor whose component values are all constant expressions is a derived-type constant expression. ANSWER: Yes, there is a flaw in Section 5.2.9 in the text description of the values permitted in a DATA statement. The following edits eliminate this flaw. Discussion: In considering the edits to Section 5.2.9 to repair this flaw, it became apparent that the second sentence in the third paragraph following the constraints, [53:4-5] "Each such value ... host association." applied equally to named constants and structure constructors. This means that the type definition for the structure constructor must be accessible. Furthermore, this should be stated as a constraint. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.2.9, 2.4.3.1.2, 3.2.3, 4.4.4 EDITS: 1. Add a new constraint after the second constraint following R537: If a DATA statement constant value is a named constant or a structure constructor, the named constant or derived type must have been declared previously in the scoping unit or made accessible by use or host association. 2. Delete the second sentence in the third paragraph following the constraints [53:4-5], "Each such value ...host association." 3. In the third sentence [53:6], replace "following constant" with "following constant value". 4. In the next two paragraphs [53:11, 17], change "constant" to "constant value" (twice) 5. In the sixth paragraph [53:18, 19], change "constant" to "constant or structure constructor" (twice) SUBMITTED BY: Larry Rolison - X3J3/92-221 LAST SIGNIFICANT CHANGE: 1993-02-10 000089 HISTORY: Submitted as X3J3/92-221 at Meeting 123 Draft response X3J3/93-032 prepared for consideration at Meeting 124 Revised as X3J3/93-032r1 based on comments from Rolison and adopted at meeting 124 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000091 TITLE: Constraint diagnosis for PRIVATE attribute KEYWORDS: PRIVATE, modules, constraints DEFECT TYPE: Interpretation STATUS: X3J3 draft response 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: Yes Discussion: Module A by itself is standard-conforming. It is not until module A is used by module B that the cited constraints are violated. REFERENCES: ISO/IEC 1539:1991 (E) sections 1.4, 4.4.1, and 5.2.3 EDITS: None. SUBMITTED BY: Maureen Hoffert LAST SIGNIFICANT CHANGE: 1993-02-10 00091 HISTORY: Submitted at 123 in X3J3/92-225. Response in X3J3/93-024 adopted at meeting 124 by a vote of (14-3) -------------------------------------------------------------------------- NUMBER: 000092 TITLE: Pointer and Storage Association KEYWORDS: pointer association, storage association, ASSOCIATED DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following example program: PROGRAM PROG INTEGER :: VAR COMMON /COM/ VAR VAR = 5 CALL SUB END PROGRAM PROG SUBROUTINE SUB INTEGER,POINTER :: PTR INTEGER,TARGET :: TGT COMMON /COM/ TGT PTR => TGT ... END SUBROUTINE SUB Is the pointer assignment legal? Although the entity named TGT was declared with the TARGET attribute, a storage associated entity, VAR, was not. ANSWER: The pointer assignment is legal only because PTR is declared within the scoping unit of SUB and is not accessible outside the scoping unit of SUB. Discussion: By the rules of 6.3.3.2, PTR becomes undefined upon return from SUB to the calling program. Note however that if PTR was also accessible in the scoping unit PROG and the variable VAR was not declared with the TARGET attribute, the program would not be standard conforming. The following example is not standard conforming. PROGRAM PROG INTEGER :: VAR INTEGER,POINTER :: PTR COMMON /COM/ VAR, PTR VAR = 5 CALL SUB ... END PROGRAM PROG SUBROUTINE SUB INTEGER,POINTER :: PTR INTEGER,TARGET :: TGT COMMON /COM/ TGT, PTR PTR => TGT ... END SUBROUTINE SUB After the call to SUB, PTR is pointer associated with the same storage that VAR is storage associated with. In this case, VAR must be declared with the TARGET attribute in the scoping unit PROG for the program to be standard conforming. REFERENCES: ISO/IEC 1539:1991 (E) section 6.3.3.2. EDITS: None. SUBMITTED BY: Len Moss LAST SIGNIFICANT CHANGE: 1993-02-10 000092 HISTORY: Issue arose during Victoria (1992) WG5 meeting, while reviewing various questions concerning S20.121(27) Separate request submitted following meeting 121 Submitted as X3J3/92-226 at meeting 123 Response in X3J3/93-034r adopted at meeting 124 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000093 TITLE: Scalar Pointer Function Results KEYWORDS: function results, pointer attribute DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: May a scalar function result have the pointer attribute? ANSWER: Yes. Discussion: The text that appears as the last paragraph of 5.1.2.4.3 is intended to apply to all function results even though it appears in a section titled, "Deferred-shape array". To clarify this point, the edit below moves that text to section 5.2 which has the more general title, "Type declaration statements". REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1 and 5.1.2.4.3 EDIT: Delete the last paragraph of 5.1.2.4.3 [46:43]. Insert the following paragraph after the second paragraph following the constraints in 5.1 [40:38+] A function result may be declared to have the pointer attribute. SUBMITTED BY: Len Moss - X3J3/92-227 LAST SIGNIFICANT CHANGE: 1993-02-10 000093 HISTORY: Submitted as X3J3/92-227 at meeting 123 Proposed response in X3J3/93-075 adopted at meeting 124 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000097 TITLE: Specification Expression KEYWORDS: constant expression, specification expression DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTIONS: In section 7.1.6.2 "Specification expression": 1. In item (9) should not the restriction "defined by an ALLOCATE statement" be "allocatable" instead? That is, the ALLOCATE statement does not have to exist, it is being allocatable -- even if never allocated -- that is restricted. [79:14-15] And the same comment re pointer assignment. [79:14-15] 2. Would Item (9) be clarified if "local" were inserted before "variable"? [79:14] 3. In the text beginning "and where any subscript ..." should not "is" be "must be"? As written it says that any subscript is a restricted expression. [79:17] 4. In the text beginning "A specification expression (R509, R514, R515)... should not the "(R509, R514, R515)" be deleted? ANSWER: 1. Yes, see edits below. Edits are provided for similar problems in other sections. 2. No. 3. No, this is part of a long and complex sentence which begins on the previous page. 'Is' is the correct form and parallels the rest of the sentence and describes what a restricted expression 'is', not what a subscript is. 4. There is redundancy, but not an error. REFERENCES: ISO/IEC 1539:1991 (E) sections 7.1.6.1, 7.1.6.2 EDITS: Replace 7.1.6.1 (6), in the first list, with the following: (6) A reference to a) an array inquiry function (13.10.15) other than ALLOCATED b) the bit inquiry function BIT_SIZE, c) the character inquiry function LEN, d) the kind inquiry function KIND, e) or a numeric inquiry function (13.10.8) where each argument of the function is either a) a constant expression b) a variable whose type parameters or bounds inquired about are not assumed, c) or a variable that does not have the ALLOCATABLE or POINTER attribute, or Replace 7.1.6.1 (6), in the second list with the following: (6) A reference to a) an array inquiry function (13.10.15) other than ALLOCATED b) the bit inquiry function BIT_SIZE, c) the character inquiry function LEN, d) the kind inquiry function KIND, e) or a numeric inquiry function (13.10.8) where each argument of the function is either a) an initialization expression b) a variable whose type parameters or bounds inquired about are not assumed, c) or a variable that does not have the ALLOCATABLE or POINTER attribute, or Replace 7.1.6.2 (9) with the following: (9) A reference to a) an array inquiry function (13.10.15) other than ALLOCATED b) the bit inquiry function BIT_SIZE, c) the character inquiry function LEN, d) the kind inquiry function KIND, e) or a numeric inquiry function (13.10.8) where each argument of the function is either a) a restricted expression b) a variable whose type parameters or bounds inquired about are not assumed, c) or a variable that does not have the ALLOCATABLE or POINTER attribute, or SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 93-02-12 000097 HISTORY: Submitted as X3J3/92-233r at meeting 123 Revised edit submitted in X3J3/93-086 at meeting 124; passed 15-2 -------------------------------------------------------------------------- NUMBER: 000100 TITLE: ASSOCIATED intrinsic and zero-sized objects KEYWORDS: Associated, Zero sized objects, Target, Pointer DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The response to defect item 000027 states what conditions must be met for the two argument form of the ASSOCIATED intrinsic function to return a value of true. It does not state what the behavior of the intrinsic is for zero sized arguments. Question 1: Can the single argument form of the ASSOCIATED intrinsic return true as its result if the argument's target is zero sized? Question 2: Can the two-argument form of the ASSOCIATED intrinsic return true when both arguments are zero sized? The following need answers only if the answer to question 2 is yes. Question 2a: If the arguments to ASSOCIATED are zero sized but of rank greater than one, must the extents of each dimension be the same for ASSOCIATED to return true? For example, what is printed by the following program? PROGRAM HUH REAL, DIMENSION(:,:), POINTER :: P1, P2 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(10:9:1, :) P2 => A(:, 10:9:1) PRINT *, ASSOCIATED (P1, P2) END Question 2b: In the following example, rank, shape, type, kind type parameters, and extent of dimensions of the zero sized arguments to ASSOCIATED match, but the second argument is not the same as the right hand side of the previous pointer assignment statement. What is the output of this program? (Does a notion of "base address" come to play for zero-sized objects as it does for nonzero-sized objects?) PROGRAM HMMM REAL, DIMENSION(:,:), POINTER :: P1 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(:, 2:1:1) PRINT *, ASSOCIATED (P1, A(:, 3:2:1)) END ANSWER: The one-argument form of ASSOCIATED is intended to return a result of true if the pointer actual argument is currently associated with a target, even if the target is zero sized. The result of the two-argument form of the ASSOCIATED function is undefined if either of the arguments is a pointer that is currently associated with a target that is zero sized or if the second argument is not a pointer but of zero size. The following edits clarify the intent. REFERENCES: ISO/IEC 1539 : 1991 section 13.13.13. EDITS: 1. Section 13.13.13 Case (ii) add the following sentence at the end If POINTER is currently associated with a zero-sized target, or TARGET is a zero-sized array, the result is undefined. 2. Section 13.13.13 Case (iii) add the following sentence after the last sentence. If either POINTER or TARGET are associated with a zero-sized array, the result is undefined. SUBMITTED BY: Jon Steidel - X3J3/92-240 LAST SIGNIFICANT CHANGE: 1993-02-10 000100 HISTORY: Submitted as X3J3/92-240 at meeting 123 Response in X3J3/93-035 adopted at meeting 124 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000105 TITLE: Parallel Evaluation of Operands and Arguments KEYWORDS: expression, operand, argument, function, parallel, concurrent DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Question 1 Does Fortran permit concurrent evaluation of operands in expressions and of actual arguments of functions? Question 2 Is the following program standard conforming? PROGRAM TEST INTEGER F,M PRINT *, F(1,M) + F(2,M) END FUNCTION F(X,M) INTEGER F,X,M M = X*X F = M+M RETURN END ANSWER: Answer 1 Yes, the standard permits a wide variety of expression evaluation models. Answer 2 No, the specific example provided is not standard conforming. Discussion: Sections 7.1.7.1, 12.4.2 and 12.5 provide information on rules for expression evaluation and argument association. Annex C section 12.5 attempts to make it clear what was intended. The use of concurrent, parallel or lazy evaluation of expressions is permitted in a standard conforming Fortran processor. Any program whose results depend on how expression evaluation is performed is not standard conforming. In the example provided in the question the PRINT statement is non-standard conforming. Section 7.1.7 contains the following prohibition: The evaluation of a function reference must neither affect nor be affected by the evaluation of any other entity within the statement. REFERENCES: ISO/IEC 1539:1991 (E) Sections 7.1.7, 12.4.2,12.5, C.12.5 EDITS: None. SUBMITTED BY: R. L. Page LAST SIGNIFICANT CHANGE: 93 Feb. 000105 HISTORY: Contributions to the discussion provided by Brian Smith Type changed from Amendment to Interpretation meeting 124 in 93-079r1. Approved by unanimous consent at meeting 124. -------------------------------------------------------------------------- NUMBER: 000106 TITLE: Multiple USE of modules; renaming rules KEYWORDS: USE, modules, accessibility, renaming DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Section 11.3.2 states More than one USE statement for a given module may appear in a scoping unit. If one of the USE statements is without an ONLY qualifier, all public entities in the module are accessible and the rename-lists and only-lists are interpreted as a single concatenated rename-list. If all the USE statements have ONLY qualifiers, only those entities named in one or more of the only- lists are accessible, that is, all the only-lists are interpreted as a single concatenated only-list. Assume the following module definition in considering the following questions. MODULE MOD INTEGER I, J, K END MODULE Question 1: If the following USE statements appear in a scoping unit, by what names are I and J accessible? USE MOD USE MOD, ONLY: X => I USE MOD, ONLY: Z => J The rules quoted above state in this case all public entities are accessible since one of the USE statements is without an ONLY qualifier. By concatenating the only-lists and rename-lists on a single rename list we have USE MOD, X => I, Z => J Is I accessible through both the name I and X, and is J accessible through both the name J and Z? Question 2: Same as question 1 without the ONLY clause. Here, all the USE statements are without ONLY clauses. USE MOD USE MOD, X => I USE MOD, Z => J Because MOD appears in a USE statement without a rename-list, are all public entities from MOD accessible by their declared name in MOD as well as any local names given in the rename-lists? That is, is I accessible by both I and X, and J accessible by both J and Z? ANSWER: In both examples, I is made accessible only as X, and J is made accessible only as Z. Discussion: The text cited in 11.3.2 allows a collection of USE statements referencing the same module to be interpreted as an equivalent single USE statement. This circumvents restrictions on list lengths that would otherwise be indirectly imposed by the source form rules on line lengths and number of continuations. In general, it is not possible to characterize the effect of such a collection as the union of the effects that each individual statement would have in the absence of the other statements. USE statements with ONLY: can be so composed but not USE statements without ONLY:, because the lists on other USE statements can limit the accessibility of entities not explicitly named in a USE statement without ONLY:. There are programming practices that can minimize the confusion this might engender: Use of multiple USE statements referencing the same module can be limited to those cases where it is required by the length of the list involved. When multiple USE statements are required, a minimum number can be used, and they can be placed one after another. If one USE statement indicates that all public entities are to be accessible (by omitting ONLY:), all can do so. The standard does not require any of these programming practices. REFERENCES: ISO/IEC 1539:1991, section 11.3.2 EDIT: None. SUBMITTED BY: Jon Steidel LAST SIGNIFICANT CHANGE: 1993-02-10, expanded discussion 000106 HISTORY: Initially drafted as X3J3/92-246 Response proposed in X3J3/92-279 meeting 123 vote (12-4) insufficient to approve Discussion section expanded in X3J3/93-106. Approved by a vote of (14-2) at meeting 124. -------------------------------------------------------------------------- NUMBER: 000108 TITLE: Referencing disassociated pointers KEYWORDS: pointer, target, association status, disassociated, array pointer, inquiry functions, referenced, defined DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: There are several places in the standard that refer to whether a disassociated pointer can be referenced. The places seem to be inconsistent in the restrictions they place on such references. In section 5.1.2.4.3 "The size, bounds, and shape of the target of a disassociated array pointer are undefined. No part of such an array may be defined, nor may any part of it be referenced except as an argument to an intrinsic inquiry function that is inquiring about argument presence, a property of the type or type parameters, or association status." In section 5.2.7 "An object that has the POINTER attribute must not be referenced or defined unless, as a result of executing a pointer assignment (7.5.2) or an ALLOCATE statement (6.3.1), it becomes pointer associated with a target object that may be referenced or defined." In section 7.1.4.1 "If the pointer is not associated with a target, it may appear as a primary only as an actual argument in a reference to a procedure whose corresponding dummy argument is declared to be a pointer." In section 7.5.2 "A pointer must not be referenced or defined unless it is associated with a target that may be referenced or defined." In section 13.7.2 "The inquiry functions RADIX, DIGITS, MINEXPONENT, MAXEXPONENT, PRECISION, RANGE, HUGE, TINY, and EPSILON return scalar values related to the parameters of the model associated with the types and kind type parameters of the arguments. The value of the arguments to these functions need not be defined, pointer arguments may be disassociated, and array arguments need not be allocated." (1) Where exactly can a pointer that is disassociated be referenced? (2) Can array pointers that are disassociated be referenced in more places than scalar pointers that are disassociated? (3) Can a pointer with an undefined association status ever be referenced? (e.g. as the argument to the KIND intrinsic in a PARAMETER statement). ANSWER: (1) A pointer that is disassociated may never be referenced. The text cited from 5.1.2.4.3 is misleading and the text cited from 13.7.2 is incomplete. With the edits below, the text becomes more precise. (2) No. (3) No. A pointer with undefined association status may be the argument to the KIND intrinsic in a PARAMETER statement, but this is not considered to be a reference. The term reference is defined in the first paragraph of section 6. Discussion: The first paragraph of section 6 defines a reference to be the appearance of a data object name or subobject designator in a context that requires its value. When a pointer appears as an argument to an inquiry intrinsic function that is inquiring about argument presence, a property of the type or type parameters, or association status, its value is not required. Thus a disassociated pointer may appear in these places. A pointer with undefined association status may appear in all of these places except as an argument to the ASSOCIATED intrinsic function. REFERENCES: ISO/IEC 1539:1991 (E) Sections 5.1.2.4.3, 5.2.7, 6, 7.1.4.1, 7.5.2, 13.7.2 EDITS: 1. Replace the text in the seventh paragraph of 5.1.2.4.3, "The size, bounds, and shape of the target ... association status." [46:25-33] with, "The size, bounds, and shape of the target of a disassociated array pointer are undefined. No part of such an array may be referenced or defined; however, the array may appear as an argument to an intrinsic inquiry function that is inquiring about argument presence, a property of the type or type parameters, or association status." 2. Replace the text in section 13.7.2 with, "The inquiry functions RADIX, DIGITS, MINEXPONENT, MAXEXPONENT, PRECISION, RANGE, HUGE, TINY, and EPSILON return scalar values related to the parameters of the model associated with the types and kind type parameters of the arguments. The value of the arguments to these functions need not be defined, pointer arguments may have undefined or disassociated association status, and array arguments need not be allocated." SUBMITTED BY: Janice C. Shepherd - X3J3/92-258 LAST SIGNIFICANT CHANGE: 1993-02-10 000108 HISTORY: Submitted as X3J3/92-258 at meeting 123 Response in 93-076 adopted at meeting 124 by a vote of (11-3) -------------------------------------------------------------------------- NUMBER: 000112 TITLE: Sequence Derived Type External Functions KEYWORDS: SEQUENCE, derived type, external functions DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Can an external function of sequence derived type be declared with a TYPE specification in the FUNCTION statement? For example, is the following a valid code fragment? TYPE (T) FUNCTION F () TYPE T SEQUENCE INTEGER I, J END TYPE T ... END ANSWER: Yes, the code fragment is valid, as an external function of sequence derived type can be declared with a TYPE specification in its FUNCTION statement. Discussion: The second paragraph of 12.5.2.2 indicates the only two conditions under which the attributes of a function result must be specified by specification statements within the function body. "If the function result is array-valued or a pointer, this must be specified by specifications of the name of the result variable within the function body." It was not intended that the syntax of allowing TYPE on a FUNCTION statement be limited to internal and module functions. The last sentence of the first paragraph of 5.1.1.7 should not be applied to function results. An edit is included for clarification. REFERENCES: 5.1.1.7, 12.5.2.2. EDIT(S): Add after the last sentence of the first paragraph of 5.1.1.7: "If the data entity is a function result, the derived type can be specified on the FUNCTION statement providing the derived type is defined within the body of the function or is accessible there by use or host association." SUBMITTED BY: Janice C. Shepherd, 92-130. LAST SIGNIFICANT CHANGE: Nov. 1992, original draft response 000112 HISTORY: Draft response proposed in 92-298 (14-4) vote at meeting 123 insufficient for approval Approved by unanimous consent at meeting 124. -------------------------------------------------------------------------- NUMBER: 000113 TITLE: Ordering of Array Specification and Initialization KEYWORDS: statement ordering, type declaration statement, initialization, shape, DIMENSION statement, attribute specification DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Fortran 90 requires that an array initialized via a DATA statement must have its array properties established by a previous specification expression (5.2.9). When an array is initialized via an =initialization-expr specification in a type declaration statement, however, there is no such requirement. For example, the code fragment, INTEGER :: I DATA I /2*1/ DIMENSION :: I(2) is prohibited by the standard, whereas the similar fragment, INTEGER :: I = (/1,1/) DIMENSION :: I(2) appears to be permitted. Is the lack of such a requirement when initializing an array in a type declaration statement an error in the standard? ANSWER: Yes, it was the intent of the committee that specifications in type declaration statements have the same restrictions as specifications in attribute specification statements. Discussion: Section 5.2 states, "The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification." Section C.5.1 also supports this intent. Thus there is evidence in the standard that the same restrictions should be applied to objects independent of whether their attributes were specified in a type declaration statement or an attribute specification statement. The edit below clarifies this intent for the initialization of arrays. REFERENCES: ISO/IEC 1539:1991 sections 5.1, 5.2, 5.2.9, and C.5.1 EDIT: Section 5.1, add the following to the end of the fifth paragraph following the constraints, "If the variable is an array, it must have its shape specified either in the type declaration statement or a previous attribute specification statement in the same scoping unit." SUBMITTED BY: Peter Griffiths LAST SIGNIFICANT CHANGE: 1993-02-11 000113 HISTORY: Initially drafted as X3J3/120-62 (120-LJM-2a) Resubmitted as X3J3/92-287 Response in X3J3/92-287r rejected at meeting 123 (8-12) Resubmitted with opposite answer at meeting 124 in X3J3/93- 080 and adopted by a vote of (15-1) -------------------------------------------------------------------------- NUMBER: 000117 TITLE: Use of MODULE PROCEDURE Statement in Internal Procedures KEYWORDS: interface block, module procedure, host association DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The second constraint in section 12.3.2.1 appears to indicate that the following program fragment is not standard conforming. Is the following code fragment standard conforming? MODULE MOD CONTAINS SUBROUTINE SUB1(I) ... END SUBROUTINE SUB1 END MODULE PROGRAM MAIN USE MOD CALL INNER CONTAINS SUBROUTINE INNER INTERFACE SUB MODULE PROCEDURE SUB1 END INTERFACE ... END SUBROUTINE END PROGRAM ANSWER: Yes. The program fragment is standard conforming. Discussion: There are several defects in the second constraint of section 12.3.2.1. First, the constraint should not restrict the program fragment that is shown nor similar ones involving generic interfaces in internal procedures within module subprograms. Second, the constraint implies that an is a scope, when it is not. An edit is included to correct these defects. REFERENCES: ISO/IEC 1539:1991 (E) Section 12.3.2.1. EDIT: Replace the second constraint in section 12.3.2.1 with "The MODULE PROCEDURE specification is allowed only if the has a and is contained in a scoping unit where each is accessible as a module procedure." SUBMITTED BY: Y. Yoshida LAST SIGNIFICANT CHANGE: 1992-11-12, new 000117 HISTORY: Question posed in X3J3/92-132 items 63,64. Response proposed in X3J3/92-318; not formally considered at meeting 123 due to a lead time problem Approved at meeting 124 by unanimous consent. -------------------------------------------------------------------------- NUMBER: 000123 TITLE: Result of INT(A) not equal to A for non-default integers KEYWORDS: intrinsic, INT DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Is the sentence in 13.13.47 "case (i): If A is of type INTEGER, INT(A)=A" incomplete? Specifically consider the case of A being non-default INTEGER kind where RANGE(A) > RANGE(INT(A)) ANSWER: No, the sentence is correct. Discussion: Case(i) does not apply when RANGE(A) > RANGE(INT(A)). The text just before the example addresses such cases: "The result is undefined if the processor cannot represent the result in the specified integer type." REFERENCES: ISO/IEC 1539:1991 (E) Section 13.13.47 EDITS: None. SUBMITTED BY: JIS X3J3/93-036(3) LAST SIGNIFICANT CHANGE: 93 Feb, new 000123 HISTORY: Question posed in 93-036 item 3. Response proposed in 93-077. Approved by unanimous consent at meeting 124. -------------------------------------------------------------------------- NUMBER: 000125 TITLE: Copy in/ Copy out of Target Dummy Arguments KEYWORDS: dummy argument, target, explicit interface, association DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Previous Fortran standards have permitted copy in/ copy out as a valid implementation for argument passing to procedures, as does Fortran 90. Fortran 90 introduces pointer and target attributes. Sections 12.4.1.1 and C.12.8 indicate that it was intended that copy in/ copy out also be a valid implementation for passing dummy arguments that have the target attribute. The following example demonstrates a case where a copy in/ copy out implementation may get different results from an implementation which does not use a copy in/ copy out method for passing arguments that have the target attribute. POINTER IPTR TARGET I IPTR => I CALL SUB (I, IPTR) ... CONTAINS SUBROUTINE SUB (J, JPTR) POINTER JPTR TARGET J PRINT *, ASSOCIATED (JPTR, J) END SUBROUTINE END Is this a flaw in the standard? ANSWER: Yes, there is a flaw in the standard. The edits supplied disallow copy in/ copy out as a valid implementation for passing dummy arguments that have the TARGET attribute. Discussion: The changes apply only to target dummy arguments. Note that the edits supplied reinforce the response to defect item 41. REFERENCES: ISO/IEC 1539:1991 (E) sections 6.3.3.2, 12.4.1.1, and C.12.8. EDITS: 1. Add another item to list in section 6.3.3.2, "(7) An actual argument that is associated with a dummy argument of the procedure that has the TARGET attribute." 2. Section 12.4.1.1, add at the end of the fourth paragraph, " If the dummy argument has the TARGET attribute, the actual argument must have the TARGET attribute and the type, type parameters, and ranks must agree." 3. Section 12.4.1.1, fifth paragraph, last sentence [173: 10-14] delete, "with a dummy argument of the procedure that has the TARGET attribute or" 4. Section 12.4.1.1, delete the sixth paragraph [173: 14-17] and replace with, "When execution of a procedure completes, a pointer which is associated with a dummy argument of the procedure that has the TARGET attribute remains associated with the actual argument." 5. Section C.12.8, delete the second paragraph through the end of the section [292: 5-37] and replace with A pointer that is associated with a dummy argument that has the TARGET attribute when execution of a procedure completes remains associated with the corresponding actual argument. REAL, POINTER :: PBEST REAL, TARGET :: B (10000) CALL BEST (PBEST, B) ... CONTAINS SUBROUTINE BEST (P, A) REAL, POINTER :: P REAL, TARGET :: A (:) ... !Find the "best" element A(I) P => A (I) RETURN END SUBROUTINE END It is illegal to associate a dummy argument that has the TARGET attribute with an actual argument that does not have the TARGET attribute. An explicit interface is required when calling a procedure which has a dummy argument that is a target. In the following example, an expression is argument associated with a target dummy argument. The presence of the explicit interface allows a processor to detect this error. POINTER P CALL FRED (P, 4.5+X) ! Invalid call to FRED PRINT *, P ... CONTAINS SUBROUTINE FRED (PTR, TGT) POINTER PTR TARGET TGT PTR => TGT RETURN END SUBROUTINE END SUBMITTED BY: Jon Steidel - X3J3/93-095 LAST SIGNIFICANT CHANGE: 1993-02-12 000125 HISTORY: Submitted as X3J3/93-095 with draft response at meeting 124 and adopted by a vote of (15-1) -------------------------------------------------------------------------- NUMBER: 000129 TITLE: Array constructors in initialization expressions KEYWORDS: array constructors, initialization expressions, implied-DO variables DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: It was likely the intent of the standard to allow the program fragment INTEGER ARRAY(3) PARAMETER ( ARRAY = (/ (ABS(I), I=-3,-1) /) ) However, according to the text in the second list in 7.1.6.1 "(/ (ABS(I), I=- 3,-1) /)" is not an initialization expression. The array constructor "(/ ABS(-3), ABS(-2), ABS(-1) /)" qualifies as an initialization expression since item (2) in the list indicates that an array constructor is an initialization expression if each element is an initialization expression, and (4) includes "An elemental intrinsic function reference of type integer or character where each argument is an initialization expression of type integer or character." The problem with the "ABS(I)" in PARAMETER ( ARRAY = (/ (ABS(I), I=-3,-1) /) ) is that "ABS(I)" is not defined as an initialization expression. It does not qualify under (4) as "I" is not an initialization expression and it does not qualify under (2) as the primary UABS(I)U is neither an initialization expression nor an implied-do variable. Is the program fragment standard conforming. ANSWER: No, the fragment is not standard conforming. In the fragment PARAMETER (ARRAY = (/ (ABS(I), I = -3, -1) /) ) and considering 7.1.6.1, second list, rule 2 ABS(I) is an element of the array constructor. It is an expression consisting of exactly one primary, a function reference. That function reference has one argument, I, which is another expression consisting of exactly one primary. That primary is not an initialization expression and thus does not meet the requirements of rule 4. Nothing could be found indicating that the intent of standard was other than that indicated above. REFERENCES: ISO/IEC 1539:1991 (E) section 7.1.6.1 EDITS: None. SUBMITTED BY: Janice C. Shepherd HISTORY: meeting 124: submitted as paper 93-027 draft response 93-088 approved -------------------------------------------------------------------------- NUMBER: 000130 TITLE: Multiple statements on line with END statement KEYWORDS: END statement DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Can the end statement of a program unit be followed on the same line with statements for another program unit? By use of a ';' one can have multiple statements appear on a single line as in: A = 1; B = A; The standard does not seem to indicate one way or another whether an END statement can be followed by another statement on the same line. Presumably the statement would belong to the next compilation unit if such use was allowed, e.g.: END; SUBROUTINE S It is hoped that the intent of the standard is that any statement appearing on the same line as a program unit END statement must appear before the END statement. Note that END; SUBROUTINE S looks very much like END SUBROUTINE S; with a slight typo. ANSWER: No, a program unit END statement cannot be followed on the same line with statements for another program unit. The text in 3.3 "Source Form" is incomplete and an edit is provided for its repair. REFERENCES: ISO/IEC 1539:1991 (E) sections 3.3.1.2 and 3.3.2.2 EDIT: Replace the first sentence of 3.3 with: A Fortran program unit is a sequence of one or more lines, organized as Fortran statements, comments, and INCLUDE lines. SUBMITTED BY: Janice C. Shepherd HISTORY: meeting 124: submitted as paper 93-059 approved response 93-095 ============================================================== LAST SIGNIFICANT CHANGE: before meeting 123 000011 3 LAST SIGNIFICANT CHANGE: 1993-02-11 000012 4 LAST SIGNIFICANT CHANGE: 1993-02-12 000027 4 LAST SIGNIFICANT CHANGE: 1993-02-11 000030 5 LAST SIGNIFICANT CHANGE: 1993-02-12 000039 6 LAST SIGNIFICANT CHANGE: 1993-02-12 000041 6 LAST SIGNIFICANT CHANGE: 1993,-02-12, revised 000070 8 LAST SIGNIFICANT CHANGE: 1992-11-12, added edits to previously proposed interpretatio 000071 9 LAST SIGNIFICANT CHANGE: 93-02-11 000073 9 LAST SIGNIFICANT CHANGE: 92-11-11, first draft response 000075 9 LAST SIGNIFICANT CHANGE: 1993-02-10 000079 10 LAST SIGNIFICANT CHANGE: 93 02 11, initial response 000082 11 LAST SIGNIFICANT CHANGE: 1992-11-10, new 000086 12 LAST SIGNIFICANT CHANGE: 1993-02-10 000087 12 LAST SIGNIFICANT CHANGE: 1993-02-10 000089 13 LAST SIGNIFICANT CHANGE: 1993-02-10 00091 13 LAST SIGNIFICANT CHANGE: 1993-02-10 000092 14 LAST SIGNIFICANT CHANGE: 1993-02-10 000093 14 LAST SIGNIFICANT CHANGE: 93-02-12 000097 15 LAST SIGNIFICANT CHANGE: 1993-02-10 000100 16 LAST SIGNIFICANT CHANGE: 93 Feb. 000105 16 LAST SIGNIFICANT CHANGE: 1993-02-10, expanded discussion 000106 17 LAST SIGNIFICANT CHANGE: 1993-02-10 000108 18 LAST SIGNIFICANT CHANGE: Nov. 1992, original draft response 000112 18 LAST SIGNIFICANT CHANGE: 1993-02-11 000113 19 LAST SIGNIFICANT CHANGE: 1992-11-12, new 000117 19 LAST SIGNIFICANT CHANGE: 93 Feb, new 000123 20 LAST SIGNIFICANT CHANGE: 1993-02-12 000125 21