PC File: 94-006a3.100 Archive: 94-006r3.A100 -------------------------------------------------------------------------------- NUMBER: 000100 TITLE: ASSOCIATED intrinsic and zero-sized objects KEYWORDS: ASSOCIATED intrinsic, zero-sized objects, target, pointer DEFECT TYPE: Erratum STATUS: Returned by WG5 for X3J3 reconsideration QUESTION: What is the behavior of the ASSOCIATED intrinsic function 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 ANSWERS: Answer 1: 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. Answer 2: No; if both arguments are zero sized, the result is either false or undefined. The following edits clarify the intent. Answer 2a: The result is false because P1 and P2 do not have the same shape. Answer 2b: The result is undefined in this case. EDITS: 1. Section 13.13.13 Case (ii) [198:37], replace by If TARGET is present and is a nonzero-sized target, the result is true if POINTER is currently associated with TARGET. If TARGET is zero sized, but has the same type, type parameters, rank, and shape as POINTER, the result is undefined. Otherwise, the result is false. 2. Section 13.13.13 Case (iii) [199:1], replace by If TARGET is present and is a pointer, the result is true if both POINTER and TARGET are currently associated with the same nonzero-sized target. If the targets are zero sized and have the same type, type parameters, rank, and shape, the result is undefined. Otherwise the result is false. The result is also false if either POINTER or TARGET is disassociated. SUBMITTED BY: Jon Steidel - X3J3/92-240 HISTORY: ui 114 (jw note) 92-240 m123 Submitted 93-035 m124 response, adopted by unanimous consent 93-111 m125 ballot, return to subgroup based on Hirchert, Maine comments. Also see Ellis comment for 000108 93-138r m125 revised response adopted 11-8. 93-255r1 m127 ballot passed 21-3 m129 WG5 #549 email, 94-4-21, J Martin, failed WG5 ballot m129 WG5 #550 email, 94-4-26, J Martin, failed WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000101 TITLE: Specification statements KEYWORDS: specification statements DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: In many cases references to "specification statements" must also include reference to type declaration and other statements. Examples are: In 11.3.3.1 page 159 "A common block and all its associated specification statements" should be changed to: "............................... and type-declaration " In 12.3.2 page 167 "... and by specification statements for the dummy arguments ..." should be changed to "........................ and type-declaration ....." In 12.5.2.2 page 175, in the first constraint "... any specification statement ..." should be changed to "... any specification or type-declaration statement ..." ANSWER: The definition of specification statement has been corrected so that the suggested (but incomplete) edits are not required. EDITS: 1. Section 2.1, R207 [8:8] change 'specification-stmt' to 'declaration-stmt' 2. Section 2.1, R214 [8:29] change 'specification-stmt' to 'declaration-stmt' 3. Section 2.3.1, following 2nd paragraph [11:13+] insert new paragraph: Specification statements are all the statements that can appear in the , except for the ENTRY and FORMAT statements. note to editor: "Specification statements", above, should be in bold. 4. Figure 2.1, [11:30] change 'Specification' to 'Declaration' 5. In note to Figure 2.1, [12:31] change 'Specification' to 'Declaration' SUBMITTED BY: Dick Weaver HISTORY: 92-244r2 m123 first submitted 92-325 m123 initial response 93-145 m125 revised questions and edits, approved 14-1 93-255r1 m127 ballot failed 16-7 94-036 m128 delete edits to section D -------------------------------------------------------------------------------- NUMBER: 000102 TITLE: Returned value for INQUIRE POSITION= on an empty file KEYWORDS: INQUIRE statement, i/o file position DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Consider the following two cases 1. Reading an empty sequential file OPEN ... POSITION='REWIND' ! positioned at initial point READ ... END= ! reads endfile record, positioned ! after endfile record BACKSPACE ... ! positioned before endfile record ! which is also the initial point INQUIRE ... POSITION= 2. Writing an empty sequential file OPEN ... POSITION='REWIND' ! positioned at initial point ENDFILE ... ! write endfile record, positioned ! after endfile record BACKSPACE ... ! positioned before endfile record ! which is also the initial point INQUIRE ... POSITION= In section 9.6.1.16, "POSITION= ..." appears to imply any of the following can be returned by the INQUIRE statement in these three cases: processor dependent - since the file has been repositioned REWIND - since the file is now at its initial point APPEND - since the file is now at its terminal point Thus even for implementations that are specified to use REWIND and APPEND, rather than a processor-dependent value, the standard would seem to be ambiguous. One implementation can return "REWIND" while another returns "APPEND". Is this ambiguity intended? ANSWER: Yes. If the file has been repositioned since the OPEN statement was executed, then the value returned by INQUIRE(POSITION=...) is processor-dependent. No particular value is required to be returned, but a few values are prohibited in certain cases. The processor is free to return any value that is not specifically prohibited by section 9.6.1.16. A standard-conforming program cannot depend on a particular value being returned in this case. If an implementation chooses to return "REWIND" or "APPEND" after a file has been repositioned, the file must currently be positioned at the same point as if it had just been opened with that same value for the POSITION specifier in the OPEN statement. An implementation must not return APPEND if the file is not positioned at its terminal point or endfile record. Similarly, it must not return REWIND if the file is not positioned at its initial point. This is not the same as saying that an implementation will return APPEND when the file is positioned at its terminal point. It need not. But if it does return APPEND, then the program can be assured that the file really is positioned at its terminal point or endfile record. EDITS: None. SUBMITTED BY: Dick Weaver, 92-245 HISTORY: 92-245r2 92-245r3 93-071 m124 passed uc 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000105 TITLE: Parallel evaluation of operands and arguments KEYWORDS: expression evaluation, argument - actual evaluation, function, parallel, concurrent DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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 C.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. In the example provided in the question the PRINT statement is not 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. EDITS: None. SUBMITTED BY: R. L. Page HISTORY: Contributions to the discussion provided by Brian Smith 92-269 (jw note) 92-327 (jw note) 93-079r1 m124 Type changed from Amendment to Interpretation m124 Approved by unanimous consent 93-111 m125 ballot accepted with Kelble, Rolison edits 94-160 m129 WG5 ballot approved with Shepherd edit 94-180 m129 Shepherd edit as per WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000106 TITLE: Multiple USE of modules; renaming rules KEYWORDS: USE statement, module, use renaming DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 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. EDIT: None. SUBMITTED BY: Jon Steidel HISTORY: 92-246 Initially drafted 92-279 Response proposed m123 vote (12-4) insufficient to approve 93-091 (jw note) 93-106 Discussion section expanded m124 Approved by a vote of (14-2) 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000108 TITLE: Referencing disassociated pointers KEYWORDS: target, pointer association status, disassociated, array pointer DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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 first two lines of the seventh paragraph of 5.1.2.4.3, "The size, bounds, and shape of the target ... association status." [46:30-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 first two sentences in section 13.7.2 [186:5] 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 values 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 HISTORY: 92-258 m123 Submitted 93-076 m124 Response, adopted by a vote of (11-3) m125 edits from X3J3 ballot 93-111 m125 ballot approved with Kelble, Leonard, Maine, O'Gara, Rolison edits. 93-150 m125 edits 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000111 TITLE: Array constructors in masked assignment statements KEYWORDS: array constructor, masked array assignment, WHERE statement/construct DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: The description of masked array assignment (section 7.5.3.2) does not specify how an array constructor referenced in such an assignment is evaluated. Is the evaluation of an array constructor controlled by the ? In particular, consider the following examples: (/ MATMUL (A, B) + 1 /) Evaluation on an element-by-element basis is not possible. (/ ((A (1 : J : I), I = 1, J), J = M, N) /) In this example, it is hard to select a particular element for evaluation. Note that unmasked evaluation of array constructors could introduce some interesting semantics; for example, consider the following two statements: where (A .NE. 0) B = 1/A (S1) where (A .NE. 0) B = (/ 1/A /) (S2) Execution of these two statements would lead to divide by zero overflow for (S2) but not for (S1)! ANSWER: No, the evaluation of an array constructor in an of a masked array assignment is not controlled by the . Discussion: The array constructor must be evaluated first, and then the assignment statement containing the array constructor is evaluated according to 7.5.3.2. An edit is supplied to clarify this. It is true that evaluation of an array constructor could cause the program to become nonstandard conforming. This is a consequence of the necessity for evaluating the array constructor without mask expression control. REFERENCES: ISO/IEC 1539:1991 (E) sections 4.5 and 7.5.3.2 EDITS: In 7.5.3.2 following the third paragraph [93:37+], insert the following paragraph: If an array constructor appears in an , the array constructor is evaluated without any masked control by the and then the is evaluated. SUBMITTED BY: Graham Barber - X3J3/92-264 HISTORY: 92-264 Submitted 92-293 m123 Proposed response failed by (10-10) 93-093 m124 Same response failed by (1-13). 93-153 m125 Opposite response approved by unanimous consent 93-255r1 m127 ballot passed 24-0 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000112 TITLE: Sequence derived type external functions KEYWORDS: SEQUENCE, derived type, external function, function - external DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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. EDITS: Add after the last sentence of the first paragraph of 5.1.1.7: [43:23] "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. HISTORY: ui 77, ui 90 (jw note) 92-298 Draft response proposed m123 (14-4) vote insufficient for approval m124 Approved by unanimous consent 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000113 TITLE: Ordering of array specification and initialization KEYWORDS: statement ordering, type declaration statement, initialization, array shape, DIMENSION statement, attribute specification statement DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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. EDIT: Section 5.1, add the following to the end of the fifth paragraph following the constraints [41:8]: "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 HISTORY: 120-62 (120-LJM-2a) Initially drafted ui 96 (131, 120-39) (jw note) 92-287 Resubmitted 92-287r m123 Response rejected (8-12) 93-080 m124 Resubmitted with opposite answer, adopted (15-1) 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000114 TITLE: subsumed by 000012 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: EDIT: SUBMITTED BY: Peter Griffiths HISTORY: ui-98 (131, 120-43) (jw note) 120-99 Initially drafted 92-288 m123 Submitted, approved uc, subsequently questioned in letter ballot 93-074 m124 Revised, adopted by uc 93-228 m126 revised to make 12, 114, 134 consistent, approved uc 93-255r1 m127 ballot failed 21-3 m127 subsumed by 000012 -------------------------------------------------------------------------------- NUMBER: 000116 TITLE: Scoping units and statement labels KEYWORDS: scoping unit, statement label DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Question 1: When does the scope change from the host to an inner scope? It makes a difference in determining when a label is a duplicate of another label in the same scope. Question 2: In the following example, are the labels considered duplicates thus making the program not standard conforming? PROGRAM EX1 10 INTEGER I 20 TYPE T 10 INTEGER T1 20 REAL T2 30 INTEGER T3 30 END TYPE Question 3: In the following example, are the labels not considered duplicates as the INTERFACE and END INTERFACE statements are in the host scope while the two interface bodies each have their own scope? PROGRAM EX2 10 INTEGER I 20 INTERFACE 10 SUBROUTINE S(A) 20 REAL A 30 END SUBROUTINE 10 FUNCTION F (AA) 20 REAL AA 30 END FUNCTION 30 END INTERFACE Question 4: In the following example, are the labels not considered duplicates since the internal subroutine and function are separate scoping units? MODULE 10 INTEGER I ... 20 CONTAINS 10 SUBROUTINE INNER1 ( ) 20 I = I + 1 30 END SUBROUTINE 10 FUNCTION F ( ) 20 F = 4.5 30 END FUNCTION 30 END MODULE ANSWER: Answer 1: In 2.2 a scoping unit is defined. The syntax rules for a derived type definition, a procedure interface body, and a program unit or subprogram define the extents of scoping units. Thus the TYPE, END TYPE, PROGRAM, END PROGRAM, MODULE, END MODULE, BLOCK DATA, END BLOCK DATA, SUBROUTINE, END SUBROUTINE, and FUNCTION, END FUNCTION statements define the beginning and end of such scoping units. Answer 2: The example is not standard conforming because there are duplicate labels in the scoping unit of the derived type since the TYPE statement is part of the derived type. Answer 3: The example is standard conforming and does not have duplicate labels. Answer 4: The labels for the internal subroutine and function are not considered duplicates since they are in separate scoping units. EDIT: None SUBMITTED BY: Janice C. Shepherd HISTORY: ui 70 (132/1,2) (jw note) 92-304 m123 approved by uc 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000117 TITLE: Use of MODULE PROCEDURE statement in internal procedures KEYWORDS: interface block, module procedure, host association DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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. EDIT: Replace the second constraint in section 12.3.2.1 [167:31] 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 HISTORY: ui 85 (132/63, 64) (jw note) 92-132 items 63,64. Question posed 92-318 m123 Response proposed, not formally considered due to a lead time problem m124 Approved uc 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000121 TITLE: ";" As a Statement Separator KEYWORDS: source form - statement separator, ";" DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Are the following cases legal? (1) C = A ; + B (2) F = ; & G (3) P = Q ANSWER: Only case (3) is conforming. DISCUSSION: The phrase "partial statements," used in 3.3.2.2, was intended to describe the strictly lexical entity resulting when a line is continued in mid-statement. A statement interrupted by continuation, and the associated portion on the subsequent line, are two partial statements. Thus it was intended that breaking a statement into two partial statements be accomplished by continuation only, and not also by the ``;'' separator. Regarding case (3), it was intended that the semicolon separator be optional. It is possible to reword the first sentence of 3.3.2.2 (and 3.3.1.2) to completely avoid the use of the phrase "partial statements," while making more concise the intention of the standard committee. With these edits, the following are conforming examples, as is case (3), and cases (1) and (2) are nonconforming. F = & G ; P = & ! conforming Q F = & G ; P = Q ! conforming F = G ; P = & ! conforming Q EDITS: 1. Section 3.3.1.2 [22:44-45], change the first sentence to read as follows: "The character ``;'' terminates a statement, except when the ``;'' appears in a character context or in a comment. This optional termination allows another statement to begin following the ``;'' on the same line. A ``;'' must not appear as the first nonblank character on a line." 2. Section 3.3.1.2 [23:1-2], eliminate the last sentence of this section (it becomes redundant with edit 1). 3. Section 3.3.2.2 [23:36-37], change the first sentence to read as follows: "The character ``;'' terminates a statement, except when the ``;'' appears in a character context or in a comment. This optional termination allows another statement to begin following the ``;'' on the same line. A ``;'' must not appear as the first nonblank character on a line." 4. Section 3.3.2.2 [23:39-40], eliminate the last sentence of this section (it becomes redundant with edit 3). SUBMITTED BY: Paul St. Pierre, 119-PSP-1 HISTORY: 119-PSP-1 (initial submission) ui 94 (jw note) 92-284 m123 considered 94-072r1 m128 new response approved uc 94-116 m129 X3J3 ballot failed 13-10 -------------------------------------------------------------------------------- NUMBER: 000122 TITLE: Intrinsic procedures in modules KEYWORDS: intrinsic procedure, module DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: A standard-conforming processor is permitted (1.4) to add nonstandard intrinsic procedures, even when such procedures change the meaning of an otherwise standard-conforming program. Is such a processor permitted to "package" such nonstandard intrinsic procedures into a (non-Fortran-expressible) module, so that they would only be visible in scoping units that access the module via USE association? For example, suppose a vendor provides (possibly built into the compiler) a module, WAY_COOL, containing a function named NEAT_STUFF which takes a single default integer argument and returns a default integer result. Is the vendor permitted to define NEAT_STUFF to be a nonstandard intrinsic? If so, if the following program is submitted to this processor, which version of NEAT_STUFF (the user's or the vendor's) is invoked in each subroutine? PROGRAM HOT_STUFF CALL YOURE_HOT CALL YOURE_NOT END PROGRAM SUBROUTINE YOURE_HOT USE WAY_COOL PRINT *, NEAT_STUFF(42) END SUBROUTINE SUBROUTINE YOURE_NOT PRINT *, NEAT_STUFF(43) END SUBROUTINE FUNCTION NEAT_STUFF(NOT) NEAT_STUFF = NOT END FUNCTION ANSWER: 1. Yes. A standard-conforming processor may package additional intrinsic procedures in a module, even though not expressible in Fortran, in order to facilitate control of their visibility through USE association. Section 1.4 only restricts processor extensions to not conflicting with the standard forms and relationships (and grants an exception to this restriction for intrinsic procedures). 2. Yes. A standard-conforming processor may supply an intrinsic function, such as NEAT_STUFF in the example (1.4). This would result in the vendor's (intrinsic) NEAT_STUFF being invoked in YOURE_HOT and the user's NEAT_STUFF being invoked in YOURE_NOT. A standard-conforming processor must not reserve specific module names soley for such use as a standard-conforming program may use a module with such a selected name. Note that a program invoking the vendor's intrinsic NEAT_STUFF is not standard-conforming (section 1.4). EDITS: None SUBMITTED BY: Len Moss, X3J3/93-025 HISTORY: 93-025 submitted 93-121 proposed answer (no record in minutes of processing) 93-225 m126 draft response submitted, Approved (7-4) 93-255r1 m127 ballot failed 20-4 94-024r1 m128 proposed response, approved 16-1 94-116 m129 X3J3 ballot approved 22-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000123 TITLE: Result of INT(A) not equal to A for non-default integers KEYWORDS: INT intrinsic DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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 nondefault 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." EDITS: None. SUBMITTED BY: Hideo Wada, Chair IPSJ/ITSCJ SC22/Fortran HISTORY: 93-036 item 3 Question posed 93-077 Response proposed m124 Approved uc 93-111 m125 ballot approved 94-160 m129 WG5 approved with Rolison edit 94-186 m129 Rolison edit as per WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000124 TITLE: Result of LBOUND for assumed-size arrays KEYWORDS: LBOUND intrinsic, array assumed-size DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: The description of the value returned by LBOUND (ARRAY,DIM) does not appear to consider the case where ARRAY is an assumed-size array and DIM equals the rank of the array. Does the value returned for such a case really depend on whether the dimension DIM of ARRAY has size zero? ANSWER: No. The value returned is independent of the size of the dimension. Discussion: The text in the case (i) description of LBOUND does not include the information about the value returned for the situation where ARRAY is an assumed-size array and DIM equals the rank of the array. An edit is provided to correct that omission. EDIT: In section 13.13.52 replace the text of case (i) [214:22-25] with: "For an array section or for an array expression other than a whole array or array structure component, LBOUND(ARRAY,DIM) has the value 1. For a whole array or array structure component, LBOUND(ARRAY,DIM) has the value: (a) equal to the lower bound for subscript DIM of ARRAY if dimension DIM of ARRAY does not have extent zero or if the upper bound for dimension DIM is *; otherwise, (b) 1." SUBMITTED BY: Hideo Wada, Chair IPSJ/ITSCJ SC22/Fortran HISTORY: 93-036 m124 (4) submitted 93-096 m124 Draft response 93-146 m125 Revised response, approved unanimous consent 93-255r1 m127 ballot passed 23-1 93-324 m127 item 157 approved uc HOLD pending 157 94-034 m128 X3J3 ballot passed item 157 25-2 94-160 m129 WG5 ballot approved with edits requested 94-168 m129 requested edits as per WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000125 TITLE: Copy in/copy out of target dummy arguments KEYWORDS: argument - dummy, target, interface - explicit, argument 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 an actual argument that has the TARGET attribute to a dummy argument that has 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 such a combination of arguments. 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 an actual argument that has the TARGET attribute to a corresponding argument that has the TARGET attribute. Discussion: The changes apply only to target dummy arguments. Without the changes the behaviour of the example in the question would surprise many programmers. Other examples not involving the ASSOCIATED function are also affected by these changes in such a way that they too will have a more expected behaviour. One such example is included in the edit to section C.12.8. EDITS: 1. Section 12.4.1.1, add at the end of the fourth paragraph [173:6], "If the dummy argument has the TARGET attribute and the actual argument has the TARGET attribute, the dummy and actual arguments must have the same shape." 2. Section 12.4.1.1, fifth paragraph, last sentence [173:10-13] delete, "with a dummy argument of the procedure that has the TARGET attribute or" 3. Section 12.4.1.1, delete the sixth paragraph [173:14-17] and replace with, "If the actual argument has the TARGET attribute and the corresponding dummy argument has the TARGET attribute: (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. If the actual argument does not have the TARGET attribute and the corresponding dummy argument has the TARGET attribute, any pointers associated with the dummy argument become undefined when execution of the procedure completes." 4. Section C.12.8, delete the second paragraph through the end of the section [292:5-37] and replace with "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute. REAL, POINTER :: PBEST REAL, TARGET :: B (10000) CALL BEST (PBEST, B) ! Upon return PBEST is associated ... ! with the "best" element of 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 When the procedure BEST completes, the pointer PBEST is associated with an element of B. An actual argument without the TARGET attribute can become associated with a dummy argument with the TARGET attribute. This permits pointers to become associated with the dummy argument during execution of the procedure that contains the dummy argument. For example: INTEGER LARGE(100,100) CALL SUB(LARGE) ... CALL SUB() CONTAINS SUBROUTINE SUB(ARG) INTEGER, TARGET, OPTIONAL :: ARG(100,100) INTEGER, POINTER, DIMENSION(:,:) :: PARG IF (PRESENT(ARG)) THEN PARG => ARG ELSE ALLOCATE (PARG(100,100)) PARG = 0 ENDIF ... ! Code with lots of references to PARG If (.NOT. PRESENT(ARG)) DEALLOCATE(PARG) END SUBROUTINE SUB END Within subroutine SUB the pointer PARG is either associated with the dummy argument ARG or it is associated with an allocated target. The bulk of the code can reference PARG without further calls to the PRESENT intrinsic." SUBMITTED BY: Jon Steidel - X3J3/93-095 HISTORY: 93-095 m124 submitted with draft response and adopted (15-1) 93-111 m125 ballot, returned to subgroup based on Leonard, Maine comments. Problems with placement of edit 1, content of edit 4 93-139r m125 revised response adopted 17-1. 93-255r1 m127 ballot failed 13-10 94-092r1 m128 revised response, approved 11-5 94-116r1 m129 X3J3 ballot failed 10-13 94-177r1 m129 revised response closer to 93-255r1; approved 19-2 -------------------------------------------------------------------------------- NUMBER: 000126 TITLE: Character Entry statements and Partial Association KEYWORDS: character, ENTRY statement, function, association - partial DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: In section 14.6.3.3 there is text that indicates that partial association can occur between character entities through the use of ENTRY statements. Is this correct? ANSWER: No, the statement is not correct. Discussion: The definition of "partially associated" appears in section 14.6.3.3: "Two scalar entities are partially associated if they are associated without being totally associated." Section 12.5.2.5 'ENTRY Statements' indicates the characteristics of the result of a function named on an ENTRY statement must be the same as the characteristics of the result of the function named on the FUNCTION statement when the type of the result is character. It also indicates the result variables identify the same variable. As the result variables identify the same variable they are not partially associated. An edit is provided to correct the standard in section 14.6.3.3. EDIT(S): In section 14.6.3.3 in the sentence (last two lines of page 248) [248:40-41] "For character entities, partial association may occur only through argument association, or the use of COMMON, EQUIVALENCE, or ENTRY statements." change "COMMON, EQUIVALENCE, or ENTRY" to "COMMON or EQUIVALENCE" SUBMITTED BY: Janice C. Shepherd 93-092 HISTORY: 92-051 Based on original response 93-006.49, 93-091 (jw note) 93-092 Response 93-147 m125 Revised response, approved unanimous consent 93-255r1 m127 ballot passed 23-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000127 TITLE: Is a module a global entity? KEYWORDS: module, global entity, local entity DEFECT TYPE: Interpretation STATUS: Hold - Returned by WG5 for X3J3 reconsideration QUESTION: Consider the following program fragment: MODULE ABC INTEGER G END MODULE PROGRAM MAIN USE ABC ! Contains name ABC REAL ABC ! Contains name ABC END PROGRAM Question 1: Is a module a global entity? Question 2: May a local entity of class(1) in a scoping unit have the same name as a module accessed by that scoping unit? Question 3: May a module be accessed in a scoping unit that also accesses a local name that has the same name as the module? Specifically, in the example below can subroutine SUB reference the variable ABC? MODULE ABC INTEGER G END MODULE PROGRAM MAIN REAL ABC ! Contains name ABC ... CONTAINS SUBROUTINE SUB USE ABC ! Contains name ABC ... END SUBROUTINE END PROGRAM ANSWER: Answer 1: Yes, a module is a global entity. Answer 2: No, a local entity of class(1) in a scoping unit may not have the same name as a module accessed by that scoping unit. Answer 3: No, a module can not be referenced in a USE statement in a scoping unit that also accesses a local name that has the same name as the module. Variable ABC is not accessible by that name in the subroutine SUB. Discussion: The first sentence of Section 11 indicates that a module is a program unit. Section 14.1.1 defines global entities. The definition includes module names because the definition lists program units. Section 14.1.2 states that a name that identifies a global entity must not be used to identify a local entity of class(1). Section 11.3 [157:24-26] states: The module name is global to the executable program, and must not be the same as the name of any other program unit, external procedure, or common block in the executable program, nor be the same as any local name in the module. This would mean that the following: MODULE ABC REAL ABC END MODULE is NOT standard conforming. Section 14.1.2 [241:29-31] states: Except for a common block name (14.1.2.1) or an external function name (14.1.2.2), a name that identifies a global entity in a scoping unit must not be used to identify a local entity of class (1) in that scoping unit. The original description of host association in 12.1.2.2.1 inadvertently failed to account for module names. A correction to that section has rectified the omission (defect item 90). 12.1.2.2.1 now clearly states that the appearance of a name as the in a will prevent access by host association to an entity of the same name in the host scoping unit. EDIT: None SUBMITTED BY: Larry Rolison in x3j3/93-037 at m124. HISTORY: 93-037 m124 Submitted 93-097 m124 Draft response failed 93-148 m125 Revised response, withdrawn 93-235 m126 Revised response based on edit in item 82. approved uc 93-255r1 m127 ballot passed 24-0 HOLD per 82 93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot failed HOLD per 90 -------------------------------------------------------------------------------- NUMBER: 000128 TITLE: Use associated generic names and renaming KEYWORDS: use association, generic name, use renaming DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: In section 11.3.2 the standard indicates that if two generic interfaces are accessible in the same scoping unit and have the same name they are interpreted as a single generic interface. How does the phrase 'the same name' apply when a generic identifier has been renamed on a USE statement? More specifically, given the following module definitions: MODULE M1 INTERFACE GEN1 SUBROUTINE S1 (I) END SUBROUTINE END INTERFACE END MODULE MODULE M2 INTERFACE GEN2 SUBROUTINE S2 (I,J) END SUBROUTINE END INTERFACE END MODULE MODULE M3 INTERFACE GEN1 SUBROUTINE S3 (I) END SUBROUTINE END INTERFACE END MODULE which of the following code fragments are standard conforming? a) USE M1, GEN => GEN1 USE M2, GEN => GEN2 b) USE M1 USE M2, GEN1 => GEN2 c) USE M1 USE M3, OTHERGEN => GEN1 ! Avoid conflict with GEN1 from M1 ANSWER: The local name of a generic interface accessed through use association is the name that is significant when determining if that generic interface has the same name as any other accessible generic interface. All three code fragments are standard conforming. Discussion: In section 14.1.2.3 rules for "Unambiguous generic procedure references" are provided. These rules "must be satisfied by every pair of specific procedures that have the same generic name". In code fragment a, the generic interface named "GEN" is interpreted as a single generic interface and subroutines S1 and S2 are specific names of that interface. The rules in 14.1.2.3 also are met. In code fragment b, because GEN2 is renamed as GEN1, it is GEN1 that is the local name of the generic interface accessed from module M2. The generic interface accessed from M1 also has local name GEN1, so the two generic interfaces are treated as a single generic interface, based on the 11.3.2 rules. In code fragment c, OTHERGEN is the local name for GEN1 accessed from module M3. GEN1 is the local name for GEN1 accessed from module M1. As these local names are not the same, the generic interfaces are not treated as a single generic interface. The sentence in section 11.3.2 that states that "If two or more generic interfaces that are accessible in a scoping unit have the same name" does not clearly state that the name is a "local" name which was the intent of the standard. An edit is provided to correct this. EDIT: The sentence in section 11.3.2 that states that if two "generic interfaces that are accessible in a scoping unit have the same name" [158:26-27], change "the same name" to "the same local name". SUBMITTED BY: Janice C. Shepherd HISTORY: 93-058 m124 Submitted 93-096 m124 Draft response 93-098 (jw note) 93-149 m125 Revised response, approved 17-1 93-255r1 m127 ballot passed 24-0 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000129 TITLE: Array constructors in initialization expressions KEYWORDS: array constructor, expression - initialization, implied-DO variable DEFECT TYPE: Erratum 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 ABS(I) is neither an initialization expression nor an implied-DO variable. Is the program fragment standard conforming? ANSWER: Yes, the fragment was intended to be standard conforming. This is an error in the standard that is corrected by the edits below. EDITS: 1. In section 7.1.6.1, in the second list, in item 2 [77:39], change: "either initialization expressions or implied-DO variables" to: "initialization expressions" 2. In section 7.1.6.1, in the second list, in item 6 [78:10], delete the last "or" 3. In section 7.1.6.1, in the second list, in item 7 [78:11], change: "." to: ", or" 4. In section 7.1.6.1, in the second list, add item 8 [78:11+]: "(8) An implied-DO variable where the bounds and strides of the corresponding implied-DO are initialization expressions." SUBMITTED BY: Janice C. Shepherd HISTORY: 93-027 Submitted 93-088 Draft response approved 93-111 m125 ballot approved with Martin, Rolison edits 94-160 m129 WG5 ballot, failed 94-181r2 m129 reversed response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000130 TITLE: Multiple statements on line with END statement KEYWORDS: END statement, source form DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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. EDIT: Replace the first sentence of 3.3 [21:33] 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: 93-059 Submitted 93-094 Approved response 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000131 TITLE: Formatted Input and Kind Type Parameters KEYWORDS: kind type parameter, i/o list-directed, i/o format-directed, i/o namelist DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: The standard is unclear about the interaction of kind type parameters in formatted input records with formatted READ statements. Question 1: Which types of data, if any, can appear with kind type parameters in formatted input records with list-directed READ statements and non-list-directed formatted READ statements? Section 10.5.1.1 'Integer Editing' indicates that integer constants are valid input. As the definition of integer constant includes kind type parameters then one is to assume that valid input for integer editing includes integer constants listed with kind numbers. Section 10.5.1.2.1 'F editing' describes the exponent of a valid input field as ending with a signed integer constant, but there is no mention of a kind type parameter for a real constant. An integer constant can have a kind type parameter, but the kind type parameter is the kind type parameter for the integer constant not the real constant. Section 10.5.2 'Logical editing' indicates that the T or F in the input field can be followed by additional characters but gives no indication as to whether such characters might be a kind type parameter for the logical constant and that they should be recognized as a kind type parameter. Section 10.5.3 'Character editing' mentions that the characters transferred must have the same kind parameter as the data item, but is not clear as to whether the kind parameter can actually appear in the input field. Question 2: If kind type parameters are permitted in a formatted input field, does the field width 'w' specified in the corresponding edit descriptor include the characters that make up the kind type parameter? Question 3: If kind type parameters are permitted in a formatted input field, is it an error if the kind type parameter specified in the input field is not the same as the kind type parameter of the data item in the input list, for non-character data? ANSWER: 1) The standard should disallow kind type parameters in input data, but does not. This is an error that is corrected by the edits below. 2) Irrelevant. 3) Irrelevant. Discussion: This is an oversight in the standard, as a result of the relatively late addition of kind type parameters. REFERENCES: ISO/IEC 1539:1991(E), sections 10.5.1.1, 10.5.1.2.1, 10.5.2, 10.5.3, 10.8, 10.8.1, 10.8.2, 10.9, 10.9.1.3, 10.9.2.1 EDITS: 1. In Section 10.5.1.1, third paragraph [139:37-38], change "be in the form of an optionally signed integer constant" to "be a (R401)". note: is a BNF term. 2. In Section 10.5.1.1, fourth paragraph [139:45], change "in the form of an unsigned integer constant" to "as a ". Change "Note that an integer constant" to "Note that a ". note: This deals with output, not input, but we should make it clear that output doesn't produce kind type parameters either. 3. In Section 10.5.1.1, sixth paragraph [140:6], change "the unsigned integer constant" to "the ". 4. In Section 10.5.1.2.1 [140:25], list item (1), change "Explicitly signed integer constant" to "A followed by a ". 5. In Section 10.5.1.2.1 items (2) and (3) [140:26-27], change "an optionally signed integer constant" to "a ". 6. In Section 10.5.2, second paragraph [143:47], change "additional characters in the field" to "additional characters in the field, which are ignored". 7. In section 10.5.3, first paragraph [144:7-9], replace the last sentence with "The kind type parameter of all characters transferred and converted under control of one A or G edit descriptor is implied by the kind of the corresponding list item." 8. In Section 10.8, second paragraph [148:17], replace "constant with no kind type parameter specified." with "constant. Neither nor may have kind type parameters specified. The constant is interpreted as though it had the same kind type parameter as the corresponding list item." 9. In section 10.8.1, sixth paragraph [149:1-2], replace "character literal constant of the same kind as" with "possibly delimited sequence of zero or more s whose kind type parameter is implied by the kind of". 10. In section 10.8.2, ninth paragraph [151:7], delete "possibly are preceded by a and an underscore,". 11. In section 10.8.2, tenth paragraph [151:11], delete "possibly are preceded by a and an underscore,". 12. In Section 10.9, third paragraph [151:31-32], replace "constant with no kind type parameter specified." with "constant. Neither nor may have kind type parameters specified. The constant is interpreted as though it had the same kind type parameter as the corresponding list item." 13. In section 10.9.1.3, fifth paragraph [153:15-16], replace "character literal constant of the same kind as" with "delimited sequence of zero or more s whose kind type parameter is implied by the kind of". 14. In section 10.9.2.1, seventh paragraph [155:12], delete "possibly are preceded by a and an underscore,". 15. In section 10.9.2.1, eighth paragraph, [155:16], delete "possibly are preceded by a and an underscore,". SUBMITTED BY: Janice C. Shepherd (x3j3/93-116) HISTORY: 93-116 submitted 93-118r1 m125 Approved by unanimous consent 93-118r2 m125 Replaced response, approved by unanimous consent 93-255r1 m127 000098 subsumed 93-255r1 m127 ballot failed 23-1 93-302 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000132 TITLE: SYSTEM_CLOCK intrinsic conformance requirements KEYWORDS: SYSTEM_CLOCK intrinsic DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Does a Fortran language processor conform to the standard if it treats the intrinsic SYSTEM_CLOCK in any of the following ways? 1. Increment COUNT by 1 every .05495 seconds (18.2 times per second), but return a COUNT_RATE of 18. For this case, accuracy would be lost in the following code example: PROGRAM EXAMPLE INTEGER :: TSTART, TSTOP, RATE REAL :: TDIFF CALL SYSTEM_CLOCK (COUNT=TSTART, COUNT_RATE=RATE) CALL USERS_PROCESS_TO_BE_TIMED () CALL SYSTEM_CLOCK (COUNT=TSTOP) TDIFF = (TSTOP - TSTART) / RATE PRINT *, TDIFF, "SECONDS" ! this number has an error > 1% END 2. Increment COUNT by 10 every .05495 seconds (COUNT incremented by a total of 182 each second), and return a COUNT_RATE of 182. 3. Increment COUNT by a variable amount every .05495 seconds, and return a COUNT_RATE of 100. ANSWER: 1. Yes, this is conforming. 2. Yes, this is conforming. 3. Yes, this is conforming. Discussion: The standard states that for a system with a clock present, the processor-dependent value COUNT (13.13.104) is incremented by one for each clock count (whatever the processor defines that to be), and that COUNT_RATE is some number of processor clock counts per second. The standard does not suggest that the value returned for COUNT by one call to SYSTEM_CLOCK be "numerically one greater" than the value of COUNT from the previous call to SYSTEM_CLOCK but only that COUNT increases in some predictable manner. An edit is provided to clarify that COUNT_RATE is a processor-dependent approximation. A standard conforming processor is free to return any of its values at some time other than when COUNT increases by one. It is permissible for a processor to increment COUNT by one on every clock cycle internally, but make the return arguments for SYSTEM_CLOCK available to the user at a time granularity no finer than every 10 COUNTS for instance should it choose to do so. Note that it is even possible that the duration of one clock tick be longer or shorter than another. In this case COUNT_RATE could be the average value required to convert internal time to seconds. It should also be noted that the system clock (SYSTEM_CLOCK) and the real time clock (DATE_AND_TIME) need not be tied together. An implementation that employed "processor ticks" for the former and a phone call to an atomic clock for the latter would be standard conforming. EDIT: In section 13.13.104, SYSTEM_CLOCK, change the text for COUNT_RATE from 'the number' to 'a processor-dependent approximation to the number' [236:11] SUBMITTED BY: T. Lahey HISTORY: 93-130 m124 submitted 93-182 m125 Draft response 93-212 m126 Revised response passed (11-2) 93-255r1 m127 ballot failed 22-2 93-312 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000133 TITLE: Definition of "token" as used in section 3.3.1 KEYWORDS: token, source form - free, blanks DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: What constitutes a token for purposes of complying with the rules for blanks in section 3.3.1 "Free source form"? Specifically, are blanks permitted on either side of the underscore in a literal constant with a kind parameter (whether or )? If the kind parameter is a name, then surely the name is a token itself and cannot be part of a literal constant token. So if a literal constant with a kind parameter is two separate tokens, can't there be blanks in there somewhere? Related question: Are blanks permitted on either side of the exponent letter in a real literal constant? ANSWER: No, in free source form, blanks are not permitted on either side of an underscore that separates a literal constant from its kind type parameter, nor are they permitted on either side of an . Discussion: Section 3.3.1 describes the general rules of free source form. The general rules for the formation of tokens, which apply to both source forms, are given in 3.2. Section 3.2 states Lexical tokens are sequences of characters with indivisible interpretations that constitute the building blocks of a program. and gives examples of lexical tokens including: ... keywords, names, literal constants other than complex literal constants, operators, labels, ... Section 3.3.1 allows blanks to occur between the tokens of a complex literal constant but blanks are not allowed within any other literal constant form because such other literal constants are, by 3.2, (indivisible) lexical tokens. EDITS: None. SUBMITTED BY: T. Lahey and M. Snyder HISTORY: 93-131r1 m125 Submitted 93-219 m126 Draft response, approved uc 93-255r1 m127 ballot passed 23-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000134 TITLE: subsumed by 000012 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: EDITS: SUBMITTED BY: Dick Weaver HISTORY: 93-155 m125 submitted 93-215r2 m126 Proposed response, adopted uc 93-255r1 m127 ballot failed 22-2 m127 subsumed by 000012 -------------------------------------------------------------------------------- NUMBER: 000135 TITLE: INTENT(IN) conformance KEYWORDS: INTENT(IN) attribute, conformance DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 1.4, Conformance, states An executable program (2.2.1) is a standard-conforming program if it uses only those forms and relationships described herein and if the executable program has an interpretation according to this International Standard. Consider the following fragment: SUBROUTINE A (X) INTENT(IN) :: X IF (expr) X = 1.0 The intent attribute (5.1.2.3) specifies that X must not be redefined or become undefined during the execution of the procedure. Does the use of X in this fragment meet both conformance requirements -- using only those forms and relationships described herein -- the executable program has an interpretation (assume that expr is false) according to this International Standard? If "yes", was it the intent of the standard that a conforming processor not reject this program until X=1.0 is executed? ANSWER: No, the use of X in this fragment does not meet the conformance requirements of using only forms and relationships described in the standard. However, the existing wording of the standard could be interpreted to imply that the fragment was conforming if expr were always false. The edits below clarify that the fragment is non-conforming whether or not it is executed. REFERENCES: ISO/IEC 1539:1991 (E) sections 1.4 and 5.1.2.3. EDITS: 1. Section 1.4 second paragraph, first sentence [2:4] change 'uses' to 'contains' 2. Section 1.4 sixth paragraph, first sentence [2:39] change 'use' to 'contain' SUBMITTED BY: Dick Weaver HISTORY: 93-156 m125 initial submission 93-191 m126 proposed response 93-208 m126 revised response, approved uc 93-255r1 m127 ballot failed 21-3 93-326 m127 response approved uc 94-034 m128 X3J3 ballot failed 25-2 94-091 m128 additional edit supplied, approved 16-1 94-116 m129 X3J3 ballot failed 10-13 -------------------------------------------------------------------------------- NUMBER: 000136 TITLE: scalar-structure-component in data-implied-do KEYWORDS: DATA statement DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: R536 states that a can be a . 5.2.9, first paragraph following the constraint, states "A variable ... must not be initialized more than once in an executable program." Thus (A%B, I = 1,1) is conforming while (A%B, I = 1,2) is not conforming Is there a constraint missing, along the lines of must have at least one with a ANSWER: Yes. This is an oversight that is corrected with the edit specified below. Discussion: The DATA implied-DO is intended to be used as an iterative mechanism to initialize part or all of an array. The BNF metaterm must be included in R536 to allow an array of structures to be initialized. Note that the BNF metaterm (R615) defines the term "array element" to apply to a designator only when a subscript list is present on the rightmost of the . Therefore, A%B(10) is an array element designator but A(10)%B is a scalar structure component designator (assuming B is scalar). Since the DATA implied-DO is intended to be used with arrays, allowing a form such as DATA (A%B, I = 1, 1) ... was not intended and provides no useful language functionality. EDIT: In section 5.2.9, following the second constraint [52:20], insert the following constraint: Constraint: The must contain at least one that contains a . SUBMITTED BY: Dick Weaver HISTORY: 93-157 m125 submitted 94-045r1 m128 proposed response, approved 10-3 94-116 m129 X3J3 ballot approved 20-3 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000137 TITLE: array-element in data-implied-do KEYWORDS: DATA statement DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: R536 states that an can be a . 5.2.9, first paragraph following the constraint, states "A variable ... must not be initialized more than once in an executable program." Thus (A(2), I = 1,1) is conforming while (A(2), I = 1,2) is not conforming Is there a constraint missing, along the lines of s and s that are s must each have at least one subscript whose value is a function of the . ANSWER: The standard is insufficient in specifying the use of DATA implied-DO variables in subscript expressions but the insufficiency need not necessarily be corrected via the addition of a constraint. This was an oversight both in FORTRAN 77 and in Fortran 90 and is corrected with the edit specified below. Discussion: The DATA implied-DO is intended to be used as an iterative mechanism to initialize part or all of an array. Allowing the standard-conforming form as shown in the example was not intended and provides no useful language functionality. Note that by clarifying the intent of the standard via application of the edit produces an explicit restriction in Fortran 90 that, although intended by FORTRAN 77, was not explicitly stated. The relevant text from FORTRAN 77 is given on page 9-3, lines 13-16: Each subscript expression in the list must be an integer constant expression, except that the expression may contain implied-DO-variables of implied-DO lists that have the subscript expression within their ranges. Note that the text states that subscript expressions in a DATA implied-DO "may" contain implied-DO variables. This use of "may" was intended to allow a variable into what would otherwise be a constant expression. But it could also be taken to mean that a subscript expression "may" contain references to implied-DO variables, but the are not "required" to do so. For example, a subscript expression of the following form is allowed: DATA ((ARRAY(I+J, 3), I = 1, 10), J = 11, 21) ... This same concept was carried forward to the Fortran 90 standard. It was not the intent in either standard, however, to allow the case where no subscript expression contains a reference to the implied-DO variable as shown in the example. EDIT: In section 5.2.9, following the last paragraph [52:44+], add the following text: The of a must appear in at least one of each and contained within the range of the . Example: INTEGER ARRAY_1(5,5), ARRAY_2(5), ARRAY_3(10) DATA ((ARRAY_1(I, J+1), I = 1, 5), ARRAY_2(J+1), J = 0, 4) ... DATA ((ARRAY_3(I + J*1), I = 1, 2), J = 3, 4) ... TYPE SMALL INTEGER I(2) REAL R END TYPE TYPE(SMALL) GROUP(3) DATA ((GROUP(J)%I(K), K = 1, 2), J = 1, 3) ... Since ARRAY_1 is within the range of both I and J, its subscript list must contain references to both I and J, but since ARRAY_2 is only within the range of J, its subscript list need only reference J. The second DATA statement demonstrates that the DATA implied-DO variables need not be referenced in separate subscript expressions. The third DATA statement demonstrates that the implied-DO variables can be referenced in separate subscript lists of the same designator. In this case, note too that both J and K must be referenced in the designator since it falls within the range of both implied-DO variables. SUBMITTED BY: Dick Weaver HISTORY: 93-158 m125 submitted 94-046r1 m128 response approved 10-4 94-116 m129 X3J3 ballot failed 12-11 -------------------------------------------------------------------------------- NUMBER: 000138 TITLE: PRIVATE accessibility of a MODULE PROCEDURE KEYWORDS: PRIVATE attribute, module procedure DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: 4.4.1 "Derived Type Definition", fourth paragraph following the five constraints following R429 states If a type definition is private ... any procedure that has a dummy argument or function result that is of the type are accessible only within the module containing the definition. 5.2.3 "Accessibility Statements", third constraint, states A module procedure that has a dummy argument or function result of a type that has PRIVATE accessibility must have PRIVATE accessibility ... Noting that "accessible only within the module" is the definition of PRIVATE accessibility, it seems that the constraint requires the user to do something (specify the PRIVATE attribute) that is already specified as done per 4.4.1. Is the user required to specify PRIVATE accessibility for a module procedure that has a dummy argument or function result of a type that has PRIVATE accessibility? ANSWER: Yes. The text in 4.4.1 is a general statement of the requirement. The text in 5.2.3 is a specific statement of the requirement. EDITS: None SUBMITTED BY: Dick Weaver HISTORY: 93-159 m125 submitted 94-208r1 m129 response; approved u.c. -------------------------------------------------------------------------------- NUMBER: 000139 TITLE: INTRINSIC, EXTERNAL attribute questions KEYWORDS : INTRINSIC attribute, EXTERNAL attribute, conformance DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 5.1.2.11 "INTRINSIC attribute" states The INTRINSIC attribute specifies that an object name in a declaration containing this attribute must be the specific or generic name of an intrinsic function... Section 5.1.2.10 "EXTERNAL attribute" has similar wording Question 1: Given REAL, INTRINSIC :: SIN REAL, EXTERNAL :: ABC Are SIN and ABC object names? If so, of what objects? Question 2: Given LOGICAL, INTRINSIC :: SIN What entity is being declared with the type 'LOGICAL'? ANSWER: Answer 1: SIN and ABC are not object names. The standard should not have used 'object name' in sections 5.1.2.10 and 5.1.2.11, but the name of the appropriate syntactic class. The edits below correct these sections. Answer 2: LOGICAL is not a valid type for any SIN intrinsic; an edit is provided below to clarify that such a specification is not permitted. While the Fortran 77 standard was interpreted as allowing such specifications, no semantics were defined; thus 'LOGICAL' in this example was a noise word. In the absence of defined semantics and the inconsistency of the construct (in apparently specifying a non-existant intrinsic), no occurrences, other than those resulting from coding errors or in testing that interpretation, are anticipated in existing Fortran programs. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1,5.1.2.10, 5.1.2.11, 93-006R 000066 EDITS: 1. Section 5.1.2.10 Replace 'object name' with '' [48:26] 2. Section 5.1.2.11 Replace 'object name' with '' [48:30] 3. Section 5.1, second paragraph following the constraints [40:35-36] Replace 'An explicit type declaration statement is not required; however it is permitted. Specifying a type for a generic intrinsic function name in a ...' with 'An explicit type declaration statement confirming that type for either a specific or generic name is not required; however it is permitted. Such a ...' 4. Section 1.4.1 [3:32+] Add (6) 'FORTRAN 77 permitted the specification of a type for an intrinsic function even when there was no function defined for that type. For example: INTRINSIC SIN LOGICAL SIN This International Standard specifies (5.1) that a type declaration for an intrinsic function may only confirm the type of an existing function. Thus a standard-conforming FORTRAN 77 program specifying a type that is not defined for an intrinsic function does not conform to this International Standard. SUBMITTED BY: Dick Weaver X3J3/93-160 HISTORY: 93-160 m125 Submitted 93-183 m125 response withdrawn 93-314r1 m127 response withdrawn 94-209 m129 minor changes to response, failed 9-10 Current version is 93-314r1. 3rd and 4th edits should be dropped. -------------------------------------------------------------------------------- NUMBER: 000140 TITLE: TARGET attribute for a derived-type object with a pointer component KEYWORDS: POINTER attribute, TARGET attribute, structure, structure component DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Section 6.1.2 (page 63) states: A structure component has the INTENT, TARGET, or PARAMETER attribute if the parent object has the attribute. A constraint following R505 (page 40) states: Constraint: If the POINTER attribute is specified, the TARGET, INTENT, EXTERNAL, or INTRINSIC attribute must not be specified. This would seem to imply that a derived-type object with a pointer component could not have the TARGET attribute. Though it is informative, Annex C.4.6 (page 267) contains the following example: TYPE CELL INTEGER :: VAL TYPE (CELL), POINTER :: NEXT_CELL END TYPE CELL TYPE (CELL), TARGET :: HEAD TYPE (CELL), POINTER :: CURRENT ... CURRENT => HEAD which allows the static head of a linked list or tree. Does the structure component HEAD % NEXT_CELL contradict the text cited above from section 6.1.2 or the cited constraint following R505? ANSWER: Neither is contradicted. Discussion: The syntax rules for a derived type definition (R422 - R429) permit only the POINTER and DIMENSION attributes for a component, thus the TARGET keyword must not appear in a type definition. However, every pointer object has the TARGET attribute implicitly. Section 6.3.1.2 (page 68) states: Allocation of a pointer creates an object that implicitly has the TARGET attribute. While it is not possible to declare an object to have both the POINTER and TARGET attribute, every allocated pointer object possesses the TARGET attribute, so there is no problem with specifying the TARGET attribute for a derived type object containing a pointer component. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1, 6.1.2, 6.3.1.2 EDITS: None SUBMITTED BY: J. Martin in response to email May 7, 1993 from Yukimasa Yoshida HISTORY: 93-179 m125 cancelled, interpretation number then reassigned 93-181 m125 Response, Withdrawn to remove suggested edit. 93-223r m126 Response proposed, approved uc 93-255r1 m127 ballot failed 18-5 -------------------------------------------------------------------------------- NUMBER: 000141 TITLE: Generic name same as specific name KEYWORDS: generic name, specific name DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Is there a conflict between the rule given in section 14.1.2, lines 29-31, page 241, and that given is section 12.2.2.1, page 168, lines 37-39, as they apply to generic and specific names? DISCUSSION: In a generic interface block, if a specific name is an external procedure, then it is a global entity. The generic name is a local entity of class 1. Section 14.1.2, lines 29-31, page 241 states that a global name cannot be the same as a local name of class 1, unless it is an external function name. >From the reference given for external function name (14.1.2.2), it appears that the exception is meant to apply only within the external function itself. >From the above, one might conclude that a generic name cannot be the same as on 12.3.2.1, pg 168, 1. 37-39 states explicitly that "a generic name may be the same as any one of the procedure names in the interface block..." ANSWER: REFERNCES: ISO/IEC 1539:1991, sections 12.3.2.1, 14.1.2, and 14.1.2.2 EDITS: SUBMITTED BY: T. Lahey and M. Snyder HISTORY: 93-188 m126 submitted -------------------------------------------------------------------------------- NUMBER: 000142 TITLE: Namelist I/O KEYWORDS: i/o namelist, derived type, use association, PRIVATE attribute, use renaming DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION 1: Can a namelist group item be of derived type if the components of the derived type are inaccessible? Section 5.4 indicates that a namelist-group-name can't have the PUBLIC attribute if any of its items have the PRIVATE attribute. An object of derived type can have the PUBLIC attribute even if its components are private, so this text is insufficient. While Section 9.4.2 indicates that an input/output list item can not be of derived type if any of its components are not accessible, this section does not cover namelist list items. Here is an example of variables of derived type with private components appearing in namelist lists: Example 1: MODULE M TYPE T PRIVATE INTEGER I,J END TYPE TYPE (T) X NAMELIST /N1/ X END MODULE PROGRAM NN USE M TYPE (T) NX NAMELIST /N2/ NX END PROGRAM QUESTION 2: If a namelist group name or a namelist group item is accessed via use association and the USE statement supplies a rename of the group name or of the item, is it the original name that appears in the input/output record or the name introduced through renaming? Section 10.9.1 item (2) appears to indicate that for the group name it is that name that appears in the input statement that is used. Other references in sections of 10.9 do not appear to contain further details of which name to use. As renaming on USE statements is provided to limit name conflicts within the scope that has the USE statement, it appears that such renaming should not affect the names used in namelist I/O. Here is an example to consider: Example 2: MODULE M NAMELIST /N/ I, J INTEGER K END MODULE SUBROUTINE S() USE M , NN => N, JJ => J, KK => K CHARACTER J, K NAMELIST /X/ KK, K I = 1 JJ = 2 KK = 3 J = 'A' K = 'B' WRITE(10, NML=NN) WRITE(10, NML=X) END ANSWERS: 1. No. As with an input/output list, the components of any namelist group objects referenced in a namelist input/output statement which are of derived type must be accessible. An edit to clarify this is included. 2. Section 10.9.1 item (2), should indicate that the namelist group name used in the namelist input/output record is the namelist group name specified in the original namelist statement. This would be consistent with sections 10.9.1 and 10.9.2.2 which both state that the name used in the name value sequence is the name of the item from the namelist statement. In particular, the output of the supplied example (assuming that the DELIM= specifier has been assigned the value APOSTROPHE) is: &N I=1, J=2 / &X KK=3, K='B'/ An edit is provided to correct section 10.9.1 EDITS: 1. In section 5.4, add to the end of the second constraint [56:13] "or have private components" 2. In section 10.9.1, replace item (2) with [151:39-40] "The character & followed immediately by the as specified in the namelist statement," SUBMITTED BY: Janice C. Shepherd HISTORY: 93-189 submitted 93-218 m126 proposed response approved 13-1 93-255r1 m127 ballot failed 21-3 93-299r1 m127 withdrawn 94-067 m128 clarified answer 2 and added new edit. Approved uc, but then returned to status "X3J3 consideration" as meeting 127 ballot not completely addressed. 94-178 m129 altered first edit, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000143 TITLE: Use association and functions/subroutines/intrinsics KEYWORDS: use association, function, type declaration, subroutine, intrinsic procedure DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: In Fortran programs it is sometimes the way an entity is referenced that partially determines what the entity is. For example given the following specification section: INTEGER X it is not clear until X is referenced as to whether X is the name of a function or the name of a variable. If such a specification statement appears in the scope of a module, can a reference to the entity either within the module or by use association partially determine what the entity is? Section 11.3.2 indicates that the local name of an entity made accessible by use association may appear in no other specification that would cause any attribute of the entity to be respecified in the scoping unit (except the local name can appear in a PUBLIC or PRIVATE statement if the scoping unit is a module). But this section does not comment on the following example: MODULE M1 IMPLICIT INTEGER(A) INTEGER UNCLEAR1, UNCLEAR2 EXTERNAL ALSO_UNCLEAR ! Could be a subroutine or a function INTEGER SIN ! Could be a variable or an intrinsic CONTAINS SUBROUTINE XX(I) I = UNCLEAR1() ! Indicates UNCLEAR1 ! is a function not a variable. END SUBROUTINE END MODULE USE M1 WRITE(6,*) UNCLEAR1(), UNCLEAR2(), ALSO_UNCLEAR() END ANSWER: No, if the entity is accessible from the module and otherwise, yes for references within the module. Discussion: The text of 11.3.2 cited addresses attributes being specified in specification statements. The text however does not consider attributes specified by executable statements. It was the intent that attributes of use associated entities be specified within the scope of the module. An exception was made for the PUBLIC and PRIVATE attributes. An edit is provided to clarify the intent. REFERENCES: ISO/IEC 1539:1991 (E) section 11.3.2, 5.2.3 EDIT: Add at the end of the first paragraph of 5.2.3 [49:31]: "If a procedure is accessible from a module, then within the scoping unit of the module one of the following must be true: (1) if it is an intrinsic procedure, it must be given the INTRINSIC attribute or be used as an intrinsic procedure (2) the procedure must have an explicit interface (3) the procedure must be given the EXTERNAL attribute and if it is a function it must be explicitly declared in a type declaration statement. SUBMITTED BY: Janice C. Shepherd HISTORY: 93-190 m126 submitted 93-316 m127 response approved uc 94-034 m128 X3J3 ballot failed 22-6 -------------------------------------------------------------------------------- NUMBER: 000144 TITLE: Specification expressions and implicit typing. KEYWORDS: expression - specification, implicit typing, host association DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Section 7.1.6.2 indicates: A variable in a specification expression must have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit typing rules currently in effect for the scoping unit, or by host or use association. In the following code fragment, it is the appearance of the name XX in the COMMON statement that makes the entity XX of the host inaccessible. Is the use of XX in the specification expression valid, even though it occurs before the COMMON statement? INTEGER XX ... CONTAINS SUBROUTINE INNER() IMPLICIT INTEGER(X) CHARACTER*(XX) CHARAUTO COMMON /C/ XX ... Section 12.1.2.2.1 indicates that if a host entity is inaccessible only because a local entity of that name is initialized in a DATA statement, the local entity must not be referenced or defined prior to the DATA statement. A similar statement prohibiting a reference to XX prior to its declaration in the COMMON statement does not appear to exist. ANSWER: Yes. Discussion: Although the concepts may appear to be similar, DATA statements may occur throughout the executable statements while COMMON statements may not. The difference noted is deliberate. A suggestion to remove the restriction on the DATA statement would be appropriate for a future revision of the Fortran standard. EDIT: None SUBMITTED BY: Janice C. Shepherd HISTORY: 93-192 m126 submitted 93-236 m126 response, approved uc 93-255r1 m127 ballot passed 21-3 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000145 TITLE: Expressions in of a FUNCTION statement KEYWORDS: expression - specification, expression - initialization, FUNCTION statement DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: The syntax rule R1217 shows that the type and type parameters of a function can be specified in the FUNCTION statement (12.5.2.2). (a) If a appears in a FUNCTION statement, can the initialization and specification expressions of that involve names of entities that are declared within the function or are accessible there by host or use association? (b) Section 5.1 states: "The (7.1.6.2) of a (5.1.1.5) or an (5.1.2.4) may be a nonconstant expression provided the specification expression is in an interface body (12.3.2.1) or in the specification part of a subprogram." As a FUNCTION statement is not part of the specification part of a subprogram, this text in the standard appears to distinguish between FUNCTION statements that are in interface blocks and ones that are not. This text does prohibit such examples as: INTEGER I ... CONTAINS CHARACTER*(I+1) FUNCTION F() ... COMMON // I ... where it can be confusing as to which I is being referenced in the FUNCTION statement. While host association does not apply to interface bodies, for consistency should the text quoted from Section 5.1 have been "... is in the specification part of an interface body (12.3.2.1) or in the specification part of a subprogram."? (c) Section 7.1.6.1 states: "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." Was this text intended to apply to FUNCTION statements even though they are not part of any , thus disallowing fragments such as: INTEGER (KIND=KIND(X)) FUNCTION F() INTEGER(KIND=KIND(0)) X ... Similar text appears in Section 7.1.6.2. ANSWER: (a) A specification expression in the of a FUNCTION statement may involve names of entities that are declared within the function or are accessible there by host or use association, but an initialization expression in such a may only involve names that are accessible by host association. (b) No. It was not the intent of the standard to distinguish between the two types of FUNCTION statements you cite. As elaborated in the discussion of part (a), the standard intended to allow the expression of a FUNCTION statement to be a nonconstant expression. The sentence you cite is corrected with the supplied edit. (c) No, but fragments such as the one you provide are disallowed for other reasons as elaborated in the discussion of part (a). Discussion: (a) An initialization expression is a constant expression with an additional rule relating to exponentiation (7.1.6.1). Since it is a constant expression, the only names it can contain are the names of named constants, structure constructors, and intrinsic procedures. * Named constant Section 5.2.1.1 states: A named constant must not be referenced in any ... context unless it has been defined in a prior PARAMETER statement or type declaration statement using the PARAMETER attribute, or made accessible by use association or host association. Since the FUNCTION statement is the first statement of the scoping unit, there can be no prior PARAMETER statement or type declaration statement using the PARAMETER attribute, so the first clause does not apply. Likewise, no USE statement could have occurred so use association does not apply. This means that if a named constant appears in the of a FUNCTION statement, the function must be a module procedure or an internal subprogram, and the named constant must exist in (be accessible to) the containing scoping unit. This also means that a named constant must not appear in a of a FUNCTION statement of an interface body because an interface body does not access names via host association. * Structure constructor Rule R502 shows that the only opportunities for expressions to appear in s are in a or in a . However, a structure constructor can not appear in a because rule R505 shows that a must be an integer expression. Similarly, R506 shows that any initialization expression in a must be type integer. Therefore, a structure constructor can not appear in an initialization expression in the of a FUNCTION statement. * Intrinsic procedure The intrinsic procedure names or classes of intrinsic procedures that may appear in an initialization expression are given in 7.1.6.1. Rule R502 defines . The only opportunity for a to contain a is when the data type is character ( may be a ). Section 7.1.6.2 states that a specification expression is a restricted expression that is scalar, of type integer, and each operation must be intrinsic. In addition, rule (2) of 7.1.6.2 states that a primary of a specification expression can be a dummy argument that has neither the OPTIONAL nor INTENT(OUT) attribute. The following code fragment demonstrates a use of such a dummy argument: CHARACTER*(N+1) FUNCTION S(N) INTEGER, INTENT(IN) :: N Rule (2) also states that the primary can be a subobject of such a dummy argument but this part of the rule does not apply to a on a FUNCTION statement because a subobject can not be referenced before its parent object is declared and since the FUNCTION statement is the first statement of the subprogram, such a declaration could not have occurred. Rule (3) states that a primary can be a variable that is in a common block. The following code fragment demonstrates a use of such a common block member: CHARACTER*(N+1) FUNCTION S() ... COMMON N As in rule (2), rule (3) allows a subobject of such a variable but for the same reasons as above such a subobject designator can not appear in the expression. Rule (4) states that a primary may be a variable that is accessible by use association or host association. The following code fragments demonstrate uses of such variables: PROGRAM MAIN INTEGER :: N = 21 ... CONTAINS CHARACTER(LEN = 2*N) FUNCTION SS(K) ! N is host associated. ... END FUNCTION END PROGRAM and MODULE MOD INTEGER K DATA K /20/ END MODULE CHARACTER*(K*2) FUNCTION CHECK(STR) ! K is use associated. USE MOD ... END FUNCTION Rule (4) also states that the primary can be a subobject of such a use or host associated variable, but by the same reasoning as above, a subobject of a use associated variable can not appear in the expression. A structure constructor can not appear in a FUNCTION specification expression because the expression must be of type integer and any operations (which might yield an integer value from one or more structure constructors) must be intrinsic. Other rules of 7.1.6.2 state which intrinsic procedure names or classes of intrinsic procedures may appear in a specification expression. Section 7.1.6.2 also states: A variable in a specification expression must have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit type rules currently in effect for the scoping unit, or by host or use association. The discussion above regarding specification expressions has already ruled out "previous declarations" so the first clause of the cited sentence does not apply. The other clauses apply equally to a FUNCTION statement and to type declaration statements inside the function. (b) The discussion for part (a) describes which variable I in the example is being referenced in the of the FUNCTION statement. EDIT: Section 5.1, in the first sentence of the paragraph that starts "The (7.1.6.2)" [40:39-41], replace "in an interface body (12.3.2.1) or in the specification part of a subprogram" with "contained in an interface body (12.3.2.1), is contained in the specification part of a subprogram, or is in the of a FUNCTION statement (12.5.2.2)" SUBMITTED BY: Janice C. Shepherd HISTORY: 93-193 m126 submitted 94-023r1 m128 response, approved uc 94-116 m129 X3J3 ballot failed 22-1 (email from Shepherd, 116r1) -------------------------------------------------------------------------------- NUMBER: 000146 TITLE: Conformance KEYWORDS: conformance, derived type DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 1.4 "Conformance", third paragraph following the list, states: For example, a standard-conforming processor may allow a nonstandard data type. Section 4.4.1 "Derived-type definition", fifth constraint following R424, states: A derived-type type-name must not be the same as the name of any intrinsic type .... The program fragment, ..... TYPE ABC INTEGER XYZ END TYPE .... is taken to a processor that, as allowed by 1.4, has defined the nonstandard intrinsic type "ABC". Is it intended that this processor reject the program for the reason that a derived type type-name, ABC, is the same as the name of an intrinsic type? ANSWER: No. The constraint pointed to in the question is overly broad. There is no syntactic ambiguity; the constraint exists only to disallow forms that might cause confusion when the program source is read by a user. An edit is provided to restrict the scope of the constraint. Additional edits clarify that processors can allow additional intrinsics (while already referenced in section 1.4, other text is contradictory). EDITS: 1. In section 1.4, change the paragraph beginning "Note that" so that added data types are described in a manner parallel to added intrinsic procedures in the prior paragraph. [2:42] change "a nonstandard data type" to "additional intrinsic data types" 2. In section 2.5.7 [16:35-36] change "International Standard" to "International Standard or by the processor" 3. In section 4.4.1, change the fifth constraint following R424 to: [33:12-13] Constraint: A derived type must not be the same as the name of any intrinsic type defined in this standard nor the same as any other accessible derived type . SUBMITTED BY: Dick Weaver HISTORY: 93-209 m126 submitted 93-317 m127 response approved uc 94-034 m128 X3J3 ballot failed 25-2 -------------------------------------------------------------------------------- NUMBER: 000147 TITLE: Generic name resolution KEYWORDS: generic name DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Consider the following program : program ex1 interface sqrt real function usersqrt(i) integer i endfunction usersqrt endinterface call test contains subroutine test intrinsic sqrt write(*,*) sqrt(16) endsubroutine test end As I read the standard (section 14.1.2.4) the name sqrt is both generic in test (since it is a generic intrinsic) and in the host scope ex1 since it is a generic user procedure. If I understand 14.1.2.4.1 the reference to sqrt(16) should resolve to usersqrt i.e. even though the user specifies intrinsic for sqrt he ends up with a reference to a user procedure. Isn't that a little bit misleading to say the least? Contrast that with the following example where sqrt has been replaced by csqrt: program ex2 interface csqrt complex function usersqrt(i) integer i endfunction usersqrt endinterface call test contains subroutine test intrinsic csqrt write(*,*) csqrt(16) endsubroutine test end In this case csqrt is the name of a specific intrinsic procedure and the reference csqrt(16) is according to 14.1.2.4.2 to that procedure, which since the argument type is integer, is invalid. By changing from a generic to a specific intrinsic name, the call resolution changes drastically which a user could find very confusing - it seems that the intrinsic attribute confers different properties in the two cases. Is my interpretation of the standard correct? If so, was this the intended behaviour? If it was won't users find this very confusing? ANSWER: EDITS: SUBMITTED BY: Graham Barber HISTORY: 93-202 m126 submitted -------------------------------------------------------------------------------- NUMBER: 000148 TITLE: RANDOM_SEED, RANDOM_NUMBER KEYWORDS: RANDOM_SEED intrinsic, RANDOM_NUMBER intrinsic DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: (1) After executing the following sequence : CALL RANDOM_SEED CALL RANDOM_NUMBER(X) CALL RANDOM_SEED CALL RANDOM_NUMBER(Y) is it the intent of the standard that X=Y? The description of RANDOM_SEED, section 13.13.84 (p228), specifies that if no argument to RANDOM_SEED is present the processor sets the seed to a processor-dependent value. Was it the intent that the same processor- dependent value be set into the seed on all such argumentless calls to RANDOM_SEED? (2) After executing the following sequence: INTEGER SEED(2) CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(GET=SEED) CALL RANDOM_NUMBER(X2) CALL RANDOM_SEED(PUT=SEED) CALL RANDOM_NUMBER(X3) is it the intent of the standard that X2=X3? i.e. that the seed is updated on each call to RANDOM_NUMBER and that by restoring the seed value to that before the last call of RANDOM_NUMBER the last number will be generated again. There is nothing in the standard that specifies this behavior. An alternative implementation that conforms to the current standard does not update the seed on each call to RANDOM_NUMBER. Rather the put argument to RANDOM_SEED effectively initializes a sequence of numbers and remains unchanged until the next put. Whenever a put is done with a given seed the same sequence of numbers will always be generated. If a different seed is put a different seed will be generated. With this approach the value X3 has the same value as X1, not X2. ANSWER: (1) This is processor dependent. The standard states: "If no argument is present, the processor sets the seed to a processor dependent value." [228:13] This leaves the value of the seed and the method of generating that value up to the processor. Therefore, the standards committee cannot rule on whether X = Y or not. Different processors will handle this in different ways. (2) Yes. It is the intent of the standard that X2=X3. An edit is supplied to clarify that this is the intent. EDITS: In the description of RANDOM_SEED after RANDOM_NUMBER, add the text : [228:2] "The pseudo random number generator accessed by RANDOM_SEED and RANDOM_NUMBER maintains a seed that is updated during the execution of RANDOM_NUMBER and that may be specified or returned by RANDOM_SEED. Following execution of the statements CALL RANDOM_SEED(PUT=SEED1) CALL RANDOM_SEED(GET=SEED2) it is not required that SEED1 equal SEED2. However it is required that calls to RANDOM_NUMBER immediately after a call to RANDOM_SEED with a seed that is either SEED1 or SEED2 return the same sequence of pseudo random numbers. In particular, after subsequent execution of the statements CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(PUT=SEED2) CALL RANDOM_NUMBER(X2) it is required that X1=X2." SUBMITTED BY: Graham Barber HISTORY: 93-203 m126 submitted 94-051r2 m128 response, approved uc 94-116 m129 X3J3 ballot failed 12-11 94-201 m129 revised response and added edit, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000149 TITLE: Statement Function - Array constants in expressions, "composed" KEYWORDS: statement function DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: In the statement function, page 182: question 1: in the first constraint variables must be scalar, but not constants. Why? question 2: Where, in the first constraint, it states: "... scalar-expr must be composed of ...." does "composed" mean the primaries of that expression or does it extend to primaries of contained expressions? ANSWER: EDIT: SUBMITTED BY: Dick Weaver HISTORY: 93-222 m126 submitted --------------------------------------------------------------------------------