PC File: 95-006b1.100 Archive: 95-006r1.B100 -------------------------------------------------------------------------------- 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: 000103 TITLE: Statement Function with unreferenced dummy argument KEYWORDS: statement function DEFECT TYPE: Erratum STATUS: Published QUESTION: Consider the following example F(A,B,C)=A+B ! statement function, dummy-arg C not used in expr INTEGER C Since "C" is implicitly typed, must any later type definition (the INTEGER C in the example) confirm that typing? ANSWER: Yes (and therefore the example is nonstandard conforming). This is covered in the second constraint in Section 12.5.4. While that constraint appears to be about the scalar-expr "A+B", the last sentence, beginning "If a scalar...", applies to the dummy arguments as well (the 2nd constraint combines what should have been two separate constraints). The constraint will be split and clarified. EDIT: In section 12.5.4 split the second constraint at "If a scalar variable ..." [182:12] into a new constraint and add "dummy-arg-name," just before "scalar variable". SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 92-11-13 000103 HISTORY: X3J3/92-249 Submitted X3J3/92-249r m123 Approved 16-3 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000104 TITLE: Rounding formatted output KEYWORDS: i/o formatted rounding, i/o G edit descriptor, i/o edit descriptors DEFECT TYPE: Interpretation STATUS: Published QUESTION 1: The standard requires floating-point values to be rounded, on output (see 10.5.1.2.1 through 10.5.1.2.4). It does not, however, say how they are to be rounded. Always rounding up and always rounding down are allowed by the standard. Was that intended? QUESTION 2: The ISO/IEC 1539:1980 semantics for G edit descriptors assume that floating-point values are rounded down. The ISO/IEC 1539:1991 semantics for G edit descriptors assume that floating-point values are rounded to nearest If those assumptions are violated, the implementation is sometimes required to print strings of asterisks for numbers that a user might think should be printed normally. If the interpretation is that implementations must always round to nearest, to which nearest value must they round in the case of a value exactly between two representable values? ANSWERS: 1. Yes. 2. No particular rounding method is required by the standard. The above analysis of the effect of this on output formatting using the G edit descriptor in a formatted write statement is correct. This change from FORTRAN 77's behavior was made in order to suggest a particular preferred implementation, namely, round to nearest. The committee believed that this change would promote portability of programs and consistency in implementations of I/O libraries, without actually requiring any particular rounding method. The standard's description for selecting between E and F editing, when the user specified a G edit descriptor, assumes that if a value to be printed is exactly between the two numbers obtained by rounding the original value up and down (to the appropriate number of decimal digits), then the magnitude of the value printed will be the absolute value of the original value rounded up. EDITS: None SUBMITTED BY: Robert Corbett, X3J3/92-268 LAST SIGNIFICANT CHANGE: ..-..-.. 000104 HISTORY: X3J3/92-268 Submitted X3J3/92-299 m123 Approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000105 TITLE: Parallel evaluation of operands and arguments KEYWORDS: expression evaluation, argument - actual evaluation, function, parallel, concurrent DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 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 N981 m131 WG5 approved -------------------------------------------------------------------------------- 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: 000107 TITLE: USE renaming of generic and specific interfaces KEYWORDS: generic name, specific name, use renaming DEFECT TYPE: Interpretation STATUS: Published QUESTION: A module contains a generic interface whose name matches the name of a specific interface defined in the interface block defining the generic interface. When the module is used, the name of the generic interface appears in a rename-list on the USE statement. Does the rename apply also to the specific interface? For example: MODULE MOD INTERFACE GEN SUBROUTINE GEN (A, B) REAL A, B END SUBROUTINE END INTERFACE END MODULE SUBROUTINE USER (X) USE MOD, RENAME => GEN ! Renames generic and specific GEN DIMENSION GEN (100) ! Legal to have local variable by name GEN? ... END SUBROUTINE ANSWER: Yes, the rename also applies to the specific name. Discussion: In the example, RENAME is the local name in USER which refers to the same entity that the name GEN refers to in MODULE MOD. The name GEN is free to be used for other purposes in USER. REFERENCES: ISO/IEC 1539:1991, sections 11.3.2 EDIT: None SUBMITTED BY: Jon Steidel HISTORY: X3J3/92-247 Initially drafted X3J3/92-282 Response proposed m123 approved uc N881 WG5 approval -------------------------------------------------------------------------------- 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 edit below and the edits in defect item 159, 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." 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 N977 m131 2nd edit incorporated into 3rd edit of item 159 to avoid conflicting edits. -------------------------------------------------------------------------------- NUMBER: 000109 TITLE: Intrinsic function ASSOCIATED KEYWORDS: ASSOCIATED intrinsic DEFECT TYPE: Erratum STATUS: Published QUESTION: The description of ASSOCIATED (section 13.13.13) fails to specify that the result is scalar. Is this an oversight? Or is there some way in which an array-valued result can be returned? ANSWER: The result returned by ASSOCIATED is always scalar. The following edit makes this clear. EDIT: In 13.13.13 in the specification of the result type, add "scalar" after "default logical". [198:33] SUBMITTED BY: Graham Barber LAST SIGNIFICANT CHANGE: 92-11-13 000109 new HISTORY: X3J3/92-264 submitted X3J3/92-317 Response proposed m123 approved 18-1 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000110 TITLE: Named constant shape specification KEYWORDS: statement ordering, type declaration statement, named constant, PARAMETER statement, array shape, DIMENSION statement, attribute specification statement DEFECT TYPE: Interpretation STATUS: Published QUESTION: The standard seems inconsistent in that the following appears valid SUBROUTINE SUB ( ) REAL, PARAMETER :: R = 1 DIMENSION R (2) END while the following appears not to be SUBROUTINE SUB ( ) PARAMETER (R = 1) DIMENSION R(2) END Was this the intent? ANSWER: No, both are illegal. Discussion: Section 5.2 states, "All attributes (other than type) may be specified for entities, independently of type, by single attribute specification statements. 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 5.2.10 places the following restriction on objects named in a PARAMETER statement: "The named constant must have its type, shape, and any type parameters specified either by a previous type statement in the same scoping unit, or by the implicit typing rules currently in effect for the scoping unit." While the restriction is stated in the section titled, "The PARAMETER Statement", it applies to all objects with the parameter attribute. Objects with the parameter attribute may appear in subsequent specification expressions and initialization expressions. Because of this, the committee chose to require the shape of an object with the parameter attribute to be known before it is initialized and thus before it can appear in subsequent specification and initialization expressions. EDITS: None SUBMITTED BY: Peter Griffiths HISTORY: ui 99 (131, 120-43) (jw note) X3J3/120-100 Initially drafted X3J3/92-289 m123 Submitted m123 Approved 17-2 N881 WG5 approval -------------------------------------------------------------------------------- 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: 000115 TITLE: Multiple dummy arguments KEYWORDS: argument - dummy, local name DEFECT TYPE: Interpretation STATUS: Published QUESTION: Section 12.5.2.5 implies that a dummy argument in an ENTRY statement can also appear in the subprogram's FUNCTION or SUBROUTINE statement. That is, the following is standard conforming: SUBROUTINE S1(A,B,C) ... ENTRY SE1(A,B) ... END SUBROUTINE Does this imply that an entity can occur multiple times in a single list? For example, FUNCTION F2(A,B,A) ... END FUNCTION SUBROUTINE S3( ) ... ENTRY SE2(C,D,C) ... END SUBROUTINE ANSWER: Section 14.1.2 indicates that function F2 and subroutine S3 are invalid. Discussion: Section 14.1.2 lists named variables as a class (1) entity. The section also indicates that a name that identifies a local entity of one class must not be used to identify another local entity of the same class. When a dummy argument appears in both an ENTRY statement and a subprogram FUNCTION or SUBROUTINE statement, the name denotes the same local entity and not two different entities of the same class. In function F2 shown, the entity denoted by the first A is not the same entity as the second A. A similar statement can be made for the entities denoted by C in subroutine S3. In both cases, the fragments are attempting to use the same name for two entities of the same class and are therefore invalid. EDITS: None SUBMITTED BY: Tim Peters and Janice Shepherd LAST SIGNIFICANT CHANGE: 92-11-13 000115 new HISTORY: ui 49 (046, 048) (jw note) X3J3/92-048 (pg 27-29,30-34) Discussed in e-mail X3J3/92-295 m123 Response proposed - approved uc N881 WG5 approval -------------------------------------------------------------------------------- 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: 000118 TITLE: Named constructs and host association KEYWORDS: construct name, host association DEFECT TYPE: Erratum STATUS: Published QUESTION: Section 12.1.2.2.1 defines when a name appearing in a scoping unit is the name of a local entity, making inaccessible any entity of the host that has the same name as its nongeneric name. Should the appearance of a name as a construct name be on the list? ANSWER: Yes. Discussion: Section 14.1.2 indicates that construct names are local entities. An edit is included to add construct names to the list in section 12.1.2.2.1. EDIT: Add new item to the list in section 12.1.2.2.1 [164:20] and adjust the list punctuation accordingly. "(16) The name of a named construct" SUBMITTED BY: Peter Griffiths LAST SIGNIFICANT CHANGE: 92-11-13 000118 new HISTORY: ui 86 (jw note) X3J3/92-132 item 68 Submitted as a request X3J3/92-319 m123 Response proposed - approved uc N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000119 TITLE: Rank of assumed-shape array KEYWORDS: array rank, array assumed-shape, array argument DEFECT TYPE: Erratum STATUS: Published QUESTION: Must the rank of an assumed-shape dummy argument match that of the corresponding actual argument? The fourth paragraph of section 12.4.1.1 indicates that if a dummy argument is a pointer, the actual argument must be a pointer and their ranks must agree. No similar statement appears to exist for assumed-shape arrays. ANSWER: Yes. The rank of an assumed-shape dummy argument must match that of the actual argument. This is implied by the statement in 5.1.2.4.2 that an assumed-shape array takes its shape from the associated actual argument array. An edit is included to clarify this restriction. EDIT: At the end of the first paragraph of section 12.4.1.1 [172:41], add: "If the dummy argument is an assumed-shape array, the rank of the dummy argument must agree with the rank of the actual argument." SUBMITTED BY: A. Meyer LAST SIGNIFICANT CHANGE: 92-11-13 000119 new HISTORY: ui 87 (jw note) X3J3/92-132 item 69 Submitted as a request X3J3/92-320 m123 Response proposed - approved uc N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000120 TITLE: PRESENT intrinsic and host association KEYWORDS: PRESENT intrinsic, host association DEFECT TYPE: Erratum STATUS: Published QUESTION: Can the PRESENT intrinsic be called from an internal procedure with an argument that is an optional dummy argument of its host? For example SUBROUTINE HOST(OPT) REAL, OPTIONAL :: OPT ... CONTAINS SUBROUTINE INNER ( ) IF (PRESENT (OPT) ) THEN ... ANSWER: Yes. Discussion: As long as the optional dummy argument is accessible it can be used as an argument to the PRESENT intrinsic. An edit is provided for clarification. REFERENCE: ISO/IEC 1539:1991 (E) Section 13.13.80 EDIT: Replace the description of Argument in 13.13.80 [226:17] with "A must be the name of an optional dummy argument that is accessible in the procedure in which the PRESENT function reference appears." SUBMITTED BY: Janice C. Shepherd LAST SIGNIFICANT CHANGE: 92-11-13 000120 new HISTORY: X3J3/92-321 Question and proposed response first appeared N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000122 TITLE: Intrinsic procedures in modules KEYWORDS: intrinsic procedure, module DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 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 solely 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 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000123 TITLE: Result of INT(A) not equal to A for non-default integers KEYWORDS: INT intrinsic DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 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 N981 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000124 TITLE: Result of LBOUND for assumed-size arrays KEYWORDS: LBOUND intrinsic, array assumed-size DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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 ARRAY is an assumed-size array of rank DIM, or (b) 1 otherwise." 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 N977 m131 rewording of part (a) of edit and move 'otherwise'. N981 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000125 TITLE: Copy in/copy out of target dummy arguments KEYWORDS: argument - dummy, target, interface - explicit, argument association DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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 but is not an array section with a vector subscript, 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 dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. If the dummy argument has the TARGET attribute and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure. (2) When execution of the procedure completes, any pointers associated with the dummy argument remain associated with the actual argument. If the dummy argument has the TARGET attribute and the corresponding actual argument does not have the TARGET attribute or is an array section with a vector subscript, 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 and is not an array section with a vector subscript. 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 94-221 m130 X3J3 ballot, approved 21-2 94-327 m131 WG5 approved, edit changed to reflect change in corrigendum 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: 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: 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: 000136 TITLE: scalar-structure-component in data-implied-do KEYWORDS: DATA statement DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000138 TITLE: PRIVATE accessibility of a MODULE PROCEDURE KEYWORDS: PRIVATE attribute, module procedure DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 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. 94-221 m130 X3J3 ballot, approved 22-1 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000142 TITLE: Namelist I/O KEYWORDS: i/o namelist, derived type, use association, PRIVATE attribute, use renaming DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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 cannot 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. 94-221 m130 X3J3 ballot approved u.c.; accept Martin edit N984 m131 WG5 approved -------------------------------------------------------------------------------- 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: 000150 TITLE: Undefinition of implied-DO variables in I/O statements KEYWORDS: i/o statement, implied-DO variable, defined, definition, undefined DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 9.4.3 (in two places) states that when a condition such as an error condition, an end-of-file condition, or an end-of-record condition occurs, execution of the I/O statement terminates and "any implied-DO variables become undefined". Section 14.7.6, item (6) states that when any of these conditions occur, "some or all of the implied-DO variables may become undefined" and references 9.4.3. It appears the intent of the standard was that all implied-DO variables in an I/O statement in which such a condition occurs become undefined. Is that the intent of the standard? ANSWER: Yes. An edit is supplied to make the wording express this intent in both sections 9.4.3 and 14.7.6. Discussion: In several of the draft versions of Fortran 90, specifiers appeared in various I/O statements with values that depended on knowing exactly how an I/O list had been processed prior to the occurrence of an error condition. Late in the development of the standard, the committee realized that no value can be relied upon when an error occurs, and no assumptions can be made about how the I/O list has been processed. Such specifiers were removed but some related text was apparently overlooked. The standard can make no assumptions about how an implementation will process an I/O statement so it can not make any assumptions about which implied-DO variables could conceivably be still defined. Consider the following READ statement: READ *, (A(I), I = 1, 5), (B(J), J = 1, 5) If J was defined prior to the READ statement and if one of the cited conditions occurred while the first implied-DO was "active", the standard could not make the assumption that J remained defined because it could be impossible for the program or I/O system to determine that it was the first implied-DO that was active. EDITS: 1. Section 9.4.3, second paragraph following the numbered list [124:44], change any implied-DO variables become undefined to if the input/output statement contains any implied-DOs, all of the implied-DO variables in the statement become undefined 2. Section 9.4.3, second-to-last paragraph [125:7-8], change any implied-DO variables become undefined to if the input statement contains any implied-DOs, all of the implied-DO variables in the statement become undefined 3. Section 14.7.6, item (6) [251:43-45], change input/output statement, some or all of the implied-DO variables may become to input/output statement and the statement contains any implied-DOs, all of the implied-DO variables in the statement become SUBMITTED BY: Larry Rolison HISTORY: 93-243 m127 submitted 93-300 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000151 TITLE: Defined Operators with POINTER Operands KEYWORDS: defined operator, pointer DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Is it the intent of the standard that operators with pointer operands are disallowed or is this an oversight that requires correction? Consider the program below. Here a user has tried to define an operator .in. that returns true if a value is found in a tree and false if not. Unfortunately one of the arguments to LISTMEMBER is a pointer. This is rejected by the compiler because according to the standard, section 12.3.2.1.1 [169:17-18], the dummy arguments must have intent IN but pointers must not have this intent, section 5.2.1 [49:3]. It appears then that an operator with pointer operands is not allowed in Fortran-90. MODULE LIST TYPE NODE INTEGER VALUE TYPE (NODE), POINTER :: NEXT END TYPE NODE INTERFACE OPERATOR (.IN.) ! check for membership in tree MODULE PROCEDURE LISTMEMBER END INTERFACE CONTAINS ! -------------------- IS A MEMBER ? -------------------- FUNCTION LISTMEMBER(VALUE,ROOTNODE) ! If ROOTNODE is given INTENT (in) then the compiler complains that ! intent may not be given to a variable with the POINTER attribute. ! If INTENT(IN) is not ! given then the compiler complains that the dummy argument rootnode must ! have an intent (when compiling the interface definition for .IN. above). TYPE (NODE), POINTER :: ROOTNODE TYPE (NODE), POINTER :: N INTEGER, INTENT(IN) :: VALUE LOGICAL LISTMEMBER LISTMEMBER = .FALSE. N => ROOTNODE DO WHILE(ASSOCIATED(N)) IF( N%VALUE == VALUE ) THEN LISTMEMBER = .TRUE. EXIT ELSE N => N%NEXT END IF END DO END FUNCTION LISTMEMBER END MODULE LIST ANSWER: Fortran 90 does not allow defined operators with pointer operands. Dummy arguments to a defined operator must have the INTENT(IN) attribute, but pointers are not allowed to have this attribute (5.2.1, 12.3.2.1.1). EDIT: None. SUBMITTED BY: Graham Barber HISTORY: 93-247 m127 submitted 93-315 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000152 TITLE: Processor dependent values for list and namelist directed output KEYWORDS: i/o list-directed, i/o namelist DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: In Fortran 90, section 10.8.2 [150:36-37], it states For numeric output, reasonable processor-dependent integer values of w, d, and e, are used for each of the numeric constants output The previous paragraph in the section discusses the choice of 0PFw.d or 1PEw.dEe edit descriptors based on d1 and d2 processor dependent integers. This would seem to suggest that d1 and d2 are chosen once and then used for all output values. Namelist formatting, section 10.9.2.1 [154:35-40], has similar text. Question: are w, d, e, d1, and d2 chosen once and then used for all values or can different values be chosen for each numeric constant? For each numeric constant kind? If the answer is "once", then a tabular presentation results, as in the following example for a sequence of integers. 1 234 56 789 3 1000 If the answer is "chosen for each constant" then a more efficient, compact, presentation could result. 1 234 56 789 3 1000 ANSWER: All of the selection methods described in the question above are allowed. The processor is free to choose the values for w, d, e, d1, and d2 based on the value or kind of the value being printed. The processor is also free to choose permanent (fixed) values for w, d, e, d1, and d2. EDIT: None. SUBMITTED BY: Dick Weaver HISTORY: 93-248 m127 submitted 93-301 m127 response approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000153 TITLE: Defined Operations, dummy arguments INTENT(IN) KEYWORDS: INTENT(IN) attribute, defined operator DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 12.3.2.1.1 states If OPERATOR is specified in a generic specification, all of the procedures specified in the interface block must be functions that may be referenced as defined operations ..... The dummy arguments must be nonoptional dummy data objects and must be specified with INTENT(IN) .... In section C.11.4, "Example of a Module", "OPERATOR" is specified for interface blocks that specify the following procedures: ELEMENT, SUBSET, UNION, DIFFERENCE, INTERSECTION Looking at those procedures, is the example correct? ANSWER: The INTENT(IN) attribute must be explicitly specified in an operator function for each dummy argument; the attribute is not "implied". Thus, the example is incorrect. Edits are provided to correct the example. REFERENCES: ISO/IEC 1539:1991 (E) Sections 12.3.2.1.1 and C.11.4. EDITS: 1. Section C.11.4, in function ELEMENT [286:16,17], change INTEGER X to INTEGER, INTENT(IN) :: X and change TYPE (SET) A to TYPE (SET), INTENT(IN) :: A 2. Section C.11.4, in function UNION [286:21], change TYPE (SET) A, B, UNION to TYPE (SET) UNION TYPE (SET), INTENT(IN) :: A, B 3. Section C.11.4, in function DIFFERENCE [286:37], change TYPE (SET) A, B, DIFFERENCE to TYPE (SET) DIFFERENCE TYPE (SET), INTENT(IN) :: A, B 4. Section C.11.4, in function INTERSECTION [287:2], change TYPE (SET) A, B, INTERSECTION to TYPE (SET) INTERSECTION TYPE (SET), INTENT(IN) :: A, B 5. Section C.11.4, in function SUBSET [287:6], change TYPE (SET) A, B to TYPE (SET), INTENT(IN) :: A, B SUBMITTED BY: Dick Weaver HISTORY: 93-262 m127 submitted 93-325 m127 response approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot approved with Moss/Reid edit 94-179 m129 edit as per WG5 ballot N981 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000156 TITLE: Forward references to a derived type definition KEYWORDS: pointer, derived type, forward reference DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Consider the following declarations involving a reference to a derived type: Case 1: A structure declaration makes reference to a derived type definition. TYPE(DEF) :: S TYPE DEF INTEGER I, J END TYPE Case 2: A derived type definition makes reference to another derived type definition. TYPE ONE TYPE(TWO) SUBSTRUCTURE END TYPE TYPE TWO INTEGER K END TYPE Case 3: A pointer is declared to be of derived type. TYPE(THING), POINTER :: FINGER TYPE THING REAL SKIN, HAND END TYPE Case 4: A pointer component is declared to be of derived type other than the derived type of which it is a component. TYPE ONE TYPE(TWO), POINTER :: LINK END TYPE TYPE TWO INTEGER I, J END TYPE Case 5: Two pointer components are declared to be of derived types other than the derived type of which they are a component and each pointer is of the other derived type, thus tightly linking the two derived types. TYPE ONE INTEGER :: INT_FIELD TYPE(TWO), POINTER :: LINK END TYPE TYPE TWO REAL :: REAL_FIELD TYPE(ONE), POINTER :: LINK END TYPE Notice that in all of these cases, the initial derived type reference is a forward reference to the derived type's definition. For example, in Case 1, the definition of DEF follows its reference in the declaration of structure S. It seems that all of these declaration forms are prohibited by the standard because they involve forward references to derived type definitions. The relevant text is: Case 1: p. 43, lines 21-23 When a data entity is specified to be of a derived type, the derived type must have been defined previously in the scoping unit or be accessible there by use or host association. Case 2: p. 33, lines 22-23 Constraint: If the POINTER attribute is not specified for a component, a in the must specify an intrinsic type or a previously defined derived type. Case 3: Same as Case 1. Case 4: p. 33, lines 24-26 If the POINTER attribute is specified for a component, a in the must specify an intrinsic type or any accessible derived type including the type being defined. Case 5: Same as Case 4. However, the use of the word "accessible" in the paragraph cited from page 33 seems to be inexact. It could be construed to (a) be a shorthand way of saying "accessible by use association or host association" so the sentence would properly read ... or any derived type accessible by use association or host association including ... or (b) mean "available anywhere in the current scoping unit" so the sentence would properly read ... or any derived type defined in the current scoping unit or accessible by use association or host association, including ... The first case would mean that none of the cited forward reference forms are standard conforming. The second case would mean that the reference to a derived type from a pointer component of a structure (and only this case) could be a forward reference to another derived type. Did the standard intend to allow a forward reference to a derived type definition in none of the above declaration forms, in some of the above forms (which ones?), or in all of the above forms? ANSWER: Of the declaration forms shown above, the standard allows a forward reference to a derived type only in forms exemplified by Case 4 and 5. Discussion: The second supposition above about the meaning of the word "accessible" in the sentence cited from page 33 is the correct one. Note that in all declaration forms shown except Case 5, the forward reference can be removed by moving the derived type definition to precede the reference to it. Case 5 demonstrates a declaration form where the two derived types are tightly linked via the two pointers. Forward referencing can not be avoided in this form. This form and the forward referencing that goes with it needs to be allowed since a number of applications use linked list forms where a "parent" node points to a "child" and each "child" node points back at the "parent" node. EDIT(S): None. SUBMITTED BY: L. R. Rolison HISTORY: 93-269 m127 submitted 94-048r2 m128 proposed response, approved uc 94-116r1 m129 X3J3 ballot approved 22-1 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000157 TITLE: LBOUND and UBOUND return values KEYWORDS: LBOUND intrinsic, UBOUND intrinsic, zero-sized dimension, return value DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: The LBOUND intrinsic function returns the value 1 for a zero-sized dimension of an array and the UBOUND intrinsic function returns the value 0 for a zero-sized dimension of an array. X3J3 has stated a number of times in responses to public comments and in other public forums that zero-sized arrays were specifically designed into the language with all the rights and privileges of nonzero-sized arrays; that is, zero-sized arrays were not supposed to be treated like "second-class citizens". Given this informal approach and the formal way in which zero-sized arrays have been integrated into the language (see Chapters 6 and 7), it seems counter-intuitive for the LBOUND and UBOUND intrinsics to special-case zero-sized dimensions. For example, if a user declares an array as INTEGER array(10:3) the value 1 returned by LBOUND is no more meaningful than the value 10 that the user specified. In order for a program to know at run time whether or not an array or a dimension of an array has zero size, the program must still compare the lower bound to the upper bound or, better yet, use the SIZE intrinsic. Note that the same holds true for bounds that are calculated, like in ALLOCATE statements; that is, LBOUND should return the calculated value in these cases. The current descriptions of LBOUND and UBOUND seem to be incorrect with respect to zero-sized dimensions. Questions: (1) Are the descriptions of LBOUND and UBOUND, in fact, defective with respect to zero-sized dimensions (that is, should they return the lower and upper bounds as specified by the user)? (2) If the answer to the first question is No, what is the technical reason for LBOUND returning 1 and UBOUND returning 0 for a zero-sized dimension? ANSWER: (1) No. (2) There are three characteristics of each dimension of an array: the lower bound, the upper bound, and the extent. An implementation can calculate the address of an array element by maintaining the lower bound and upper bound or by maintaining the lower bound and the extent. If the standard were to require that the UBOUND intrinsic function return the declared or calculated upper bound, it would preclude implementations from maintaining dimension information via the lower bound and extent. EDIT(S): None. SUBMITTED BY: L. R. Rolison HISTORY: 93-270 m127 submitted 93-324 m127 response approved uc 000124 HELD 94-034 m128 X3J3 ballot passed 25-2 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000159 TITLE: May undefined expressions be used as arguments to INQUIRY functions KEYWORDS: inquiry functions DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 13.7.2 Numeric inquiry functions contains the phrase "The value of the arguments to these functions need not be defined", and section 13.8.5 Array inquiry functions contains the similar phrase "The values of the array arguments to these functions need not be defined" One intent is to allow inquiries about the "static" properties of variables, for example: PROGRAM EXAMPL PARAMETER (N=3) REAL AA(N,N,N,N) REAL BB(SIZE(AA)) CHARACTER*(DIGITS(AA)) CC ... where the properties of BB and CC don't depend on the numerical values of AA. However, since the arguments to functions can also be expressions, may the expressions be undefined in the more traditional sense of not having a defined result value? Consider programs like: PROGRAM EXAMPL PARAMETER (N=3) REAL AA(N,N,N,N) REAL BB(SIZE(AA + 1.0)) CHARACTER*(DIGITS(AA + 1.0)) CC ... where the expression "AA + 1.0" is undefined in the normal sense of the word since AA is undefined. Must a processor accept programs where actual argument expressions (involving one or more operators or functions references, as opposed to expressions consisting of a single variable reference) would, if evaluated, use undefined variables or produce undefined results? ANSWER: No, the intent was only to include inquiries about the attributes of undefined variables in the set of allowed inquiries. Discussion: That the resulting text applies to all expressions was unintended and edits are provided to correct this. Note that 'variable name' does not permit substrings or section-subscripts. Edits are not provided for the PRESENT or ASSOCIATED inquiry functions; neither of these permit expressions as arguments. EDITS: 1. In section 13.5.4 Character Inquiry Function [184:18-19] replace the second sentence "The value of ...." with "If the argument to this function consists of a single primary (7.1.1.1) that is a variable name, that variable need not be defined." 2. In section 13.5.7 Bit Manipulation and Inquiry Procedures [185:4-5] In the paragraph beginning "An inquiry ..." replace the second sentence "The value of ...." with "If the argument to this function consists of a single primary (7.1.1.1) that is a variable name, that variable need not be defined, if a pointer it may have undefined or disassociated association status, and if allocatable it need not be allocated." 3. In section 13.7.2 Numeric Inquiry Functions [186:7-8] replace the last sentence "The value of ...." with "If the argument to these functions consists of a single primary (7.1.1.1) that is a variable name, that variable need not be defined, if a pointer it may have undefined or disassociated association status, and if allocatable it need not be allocated." 4. In section 13.8.5 Array Inquiry Functions [187:12] replace the second paragraph "The values of ..." with "If an array argument to these functions consists of a single primary (7.1.1.1) that is a variable name, that variable need not be defined." SUBMITTED BY: Dick Hendrickson HISTORY: 93-279 m127 submitted 94-017 m128 proposed response 94-206 m129 vote on response in 94-017, approved u.c. 94-221 m130 X3J3 ballot, approved 21-2; accept Martin and Shepherd edits N977 m131 edits 2 and 3 changed to incorporate edit from item 108 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000160 TITLE: Variables with the TARGET attribute in EQUIVALENCE groups KEYWORDS: TARGET attribute, EQUIVALENCE statement, optimization DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: The intent of the TARGET attribute is to aid in optimization. Section C.5.3 states: The TARGET attribute ... is defined solely for optimization purposes. It allows the processor to assume that any nonpointer object not explicitly declared as a target may be referred to only by way of its original declared name. The rule in 5.1.2.8 ensures that this is true even if the object is in a common block and the corresponding object in the same common block in another program unit has the TARGET attribute. It is also true that pointers may point only to variables with the same type and kind type parameters. However, there are no restrictions on variables with the TARGET attribute in EQUIVALENCE statements. EQUIVALENCE statements can fully or partially storage associate variables of the same or different types and kind type parameters. It appears that variables with the TARGET attribute may become associated with variables without the TARGET attribute, or with variables which have different types. Such storage association seriously inhibits the usefulness of the TARGET attribute in optimization, be it load/store optimization or parallel optimization. This problem appears to be even more severe than that of the C language's pointer aliasing problems in that C pointers can be assumed to alias only objects with matching types. Was it the intent of the committee to allow the storage association of target variables with nontarget variables and variables of different data types? ANSWER: No, this was not the intent of the standard. Discussion: The TARGET attribute was intended to specifically identify those variables which could be associated with pointers of the same type and type parameters. It was the intent to prohibit definition or reference of a nontarget variable through a pointer. An edit is provided to clarify the intent of the standard. EDIT: After the sixth constraint of section 5.5.1 add [57:17+] Constraint: An must not have the TARGET attribute. SUBMITTED BY: Jon Steidel HISTORY: 93-293 m127 submitted 94-049r1 m128 proposed response, approved 14-5 94-116r1 m129 X3J3 ballot approved 21-2 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000162 TITLE: Pointer expression "(i)" KEYWORDS: expression - pointer, pointer DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Given the specifications INTEGER, POINTER :: I, J INTEGER :: K 1. Are the following statements equivalent? J => I J => (I) 2. Are the following statements equivalent? K = I K = (I) ANSWER: 1. No, the statements are not equivalent. Further, even assuming "I" has become pointer associated by statements not shown, the second pointer assignment is not standard conforming. 2. Yes, it is intended that the statements be equivalent; an edit is provided to clarify this intent. Discussion: 1. Data objects may have attributes, including the POINTER attribute (first paragraph of section 5). In addition, function references may "deliver a pointer result" (section 7.5.2 and 12.5.2.2). "(I)" is an expression containing a primary, "(I)", that is not a , a , or a subobject of a constant, therefore "(I)" is not a data object. As "(I)" is not a data object nor a function result, it cannot be a pointer. Section 7.5.2 defines two different semantics for pointer assignment, depending upon whether the is a pointer, so the statements are not equivalent. Section 7.5.2 states that must be a variable with the TARGET attribute, a subobject of a variable with the TARGET attribute, a variable with the POINTER attribute, or an expression delivering a pointer result. "(I)" is none of these, so the second pointer assignment is not standard conforming. 2. Section 7.1.4.1 states: "If a pointer appears as a primary in an intrinsic operation or a defined operation in which it corresponds to a nonpointer dummy argument, the associated target object is referenced." "(I)" does not involve an intrinsic operation nor a defined operation, so the exact treatment of the pointer object is not fully specified. Edits are provided to include this example in the quoted language from section 7.1.4.1. With the edits, the "I" contained in "(I)" references the target object, as does "(I)". Thus, in the assignment statement "K=I", "I" references the target of "I", as does "K=(I)", so the statements are equivalent. EDIT: 7.1.4.1: Change the first sentence of the last paragraph to: [76:18-19] "If a pointer appears as one of the following, the associated target object is referenced: (1) A primary in an intrinsic or defined operation, (2) As the of a parenthesized primary, or (3) As the only primary on the right-hand side of an intrinsic assignment statement." SUBMITTED BY: Dick Weaver HISTORY: 93-280 m127 submitted 94-198r1 m129 response approved 17-4 94-221 m130 X3J3 ballot, approved 20-3 with edits N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000163 TITLE: Pointer assignment of a disassociated pointer KEYWORDS: pointer, expression - pointer DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Consider the following example from section 7.5.2 [92], POINTER_OBJECT => POINTER_FUNCTION (ARG_1, ARG_2) and suppose that the pointer returned by pointer_function is disassociated. What happens is described in section 7.5.2 [92:17], If the is a pointer that is disassociated, the also becomes disassociated. However, noting that, in the example, 'POINTER_FUNCTION ...' is an expression, and that it is a primary, this is not valid per 7.1.4.1 [76:20-22], 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. Also see section 7.1.7 [79:41-42], If the operand is a pointer, it must be associated ... Note that, per 7.1 [70:7], An expression is formed from operands, operators, and parentheses. Thus in an expression consisting of a single primary as in the example above, that primary is an operand. Question: Is a function that returns a pointer allowed to return a disassociated pointer? ANSWER: Yes, a function that returns a pointer is allowed to return a disassociated pointer. The text in section 7.1.4.1 is in error in appearing to disallow the result to be used in a pointer assignment statement; an edit is supplied to correct this. Section 7.1.7 applies to operands only in the context of evaluation of operations, so is not applicable to the target of a pointer assignment statement (or when the operand appears as an actual argument corresponding to a pointer dummy argument). EDIT: In the final sentence of section 7.1.4.1, insert before the terminating period ", or as the target in a pointer assignment statement." [76:22] SUBMITTED BY: Dick Weaver HISTORY: 93-281 m127 submitted 94-044r1 m128 proposed response, approved 10-6 94-116r1 m129 X3J3 ballot approved 21-2 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000165 TITLE: Vector subscripts in Namelist input KEYWORDS: vector subscript, i/o namelist DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Can a namelist input record include vector subscripts? Section 10.9.1.1 indicates that if a namelist group object is an array then the input record can include a subobject of that array. ANSWER: No, vector subscripts are not allowed in a namelist input record. An edit to clarify this is included. Discussion: One commentor on a letter ballot noted that section 10.9.1.1 [152:8-9] states: "Subscripts, strides, and substring range expressions used to qualify group object names must be optionally signed integer literal constants". The commentor then concluded that since a vector subscript is not a literal constant, it is not allowed. Unfortunately, a vector subscript is not a , so additional edits are required. EDIT(S): In section 10.9.1, second paragraph [152:4], add the following sentence at the end of the paragraph: 'The optional qualification, if any, must not contain a vector subscript.' SUBMITTED BY: Janice C. Shepherd HISTORY: 93-285 m127 submitted 93-311r1 m127 response approved uc 94-034 m128 X3J3 ballot failed 18-10 94-015 m128 proposed changing meaning of 'subscript' in f95 94-195r1 m129 added discussion and revised edit, approved u.c. 94-221 m130 X3J3 ballot approved uc N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000166 TITLE: Array named constant is a constant expression? KEYWORDS: array constant DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 6.2.1 states [63:30-31]: A whole array named constant is the name of a constant expression (5.1.2.1 and 5.2.10) that is an array. Section 5.1.2.1 [44:6] has the example INTEGER, DIMENSION(3), PARAMETER :: ORDER = (/ 1, 2, 3 /) The array constructor is a constant expression, section 4.5 [38:15-16], but why is ORDER a constant expression (as opposed to just 'constant')? Consider the following 1 INTEGER, DIMENSION(3), PARAMETER :: ORDER = (/ 1, 2, 3 /) 2 INTEGER, DIMENSION(3), PARAMETER :: CHAOS = ORDER 3 INTEGER, DIMENSION(3), PARAMETER :: KAOS = (ORDER) If ORDER is the name of a constant expression, as section 6.2.1 [63] states, then -- ORDER is not a constant expression per 7.1.6.1 as it doesn't meet any of (1) through (7) -- (ORDER) is a constant expression per 7.1.6.1, meeting (7) "a constant expression enclosed in parentheses" -- neither ORDER nor (ORDER) are initialization expressions as neither meets 7.1.6.1 requirements for initialization expressions (1) through (7) and thus statements 2 and 3, above, are both invalid. ANSWER: Expressions do not have names; an edit is provided to correct this. EDIT: Section 6.2.1, second paragraph: change "the name of a constant expression (5.1.2.1 and 5.2.10)" to "a named constant (5.1.2.1 and 5.2.10)" [63:30-31] SUBMITTED BY: Dick Weaver HISTORY: 93-282 m127 submitted 94-105r1 m128 proposed response, approved uc 94-116r1 m129 X3J3 ballot approved 22-1 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000169 TITLE: End of Namelist Input KEYWORDS: i/o namelist DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: What are the values of I and A(2) after the READ statements are executed in the following? NAMELIST /NNN/ I, J INTEGER :: A(2) = 1 READ (*,NML=NNN) or NAMELIST /QQQ/ A PRINT *, I READ (*,NML=QQQ) END PRINT *,A(2); END if the input file is: &NNN I=1, J=2, &QQQ A(1)=2, I=3/ A(2)=3/ The following set of quotes from the standard implies that the value of both I and A(2) is 1, which at least is surprising and possibly not intended. Section 9.4.6 [128:22-29]: "Termination of an input/output data transfer statement occurs when any of the following conditions are met: . . . (3) Name... input reaches the end of a record after having processed a name-value subsequence for every item in the ." In the example above, after reading I=1 and J=2, condition (3) appears to be satisfied and when the end of the record (line) is reached, the I/O should terminate. A possible reaction to this is that "record" should mean everything up to and including the "/", but a) that is NOT the definition of record generally given, and b) in section 10.9.1 [152:1], item (5) it states that "A slash to terminate the namelist input statement." This is very peculiar use of the term "statement", which does not correspond to the usage elsewhere in the standard, but it must be assume that this word was used deliberately because the word "record" is not correct (being a "line"). The other thing to consider is the position of the file after completion of the READ statement. The standard states (last sentence of 9.2.1.3.3) it should be at the end of the current record, which means that if you do another READ, you would read the line "I=3/". A slight bit of evidence that all this was not intended appears in the sentence in section 10.9.1.2 [152:47-48]. "Successive namelist records are read by namelist input until a slash is encountered; ..." (10.9.1.2 Namelist Input values) or perhaps this sentence is missing the exception listed in section 9.4.6 "Termination of data transfer statements" [128:22-29]. ANSWER: After the READ statements are executed the value of I is 3 (in the program on the left) and the value of A(2) is 3 (in the program on the right). The intent of the standard was that namelist input should proceed until it reaches the terminal "/" as indicated by item 6 in section 9.4.6, unless items 4 or 5 apply. Corrections to the standard are provided. Discussion: The sentence in section 9.4.6 item 3 [128:27-28] is wrong. For namelist input, the input data transfer statement is terminated when the terminating "/" is encountered, as discussed by item 6 in the same section. EDIT(S): 1. In section 9.4.6, item 3 [128:27-29] delete "or namelist input reaches the end of a record after having processed a name-value subsequence for every item in the " 2. In 10.9.1, item (5) [152:1], delete "statement". SUBMITTED BY: Janice C. Shepherd (for Walt Brainerd) HISTORY: 93-284 m127 submitted 93-313 m127 response approved uc 94-034 m128 X3J3 ballot failed 26-1 94-203 m129 clarified answer, approved 19-1 94-221 m130 X3J3 ballot approved 22-1 with edits N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000170 TITLE: Argument Keywords and Intrinsic Procedures KEYWORDS: argument keyword, intrinsic procedure DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 14.1.2.6 'Argument Keywords' makes no mention of argument keywords associated with intrinsic procedures. Should it not include text such as the following? "A dummy argument name in an intrinsic procedure has a scope as an argument keyword of the scoping unit making reference to it." ANSWER: Yes. An edit is supplied. EDIT(S): In section 14.1.2.6 add a new paragraph after the current paragraph. [245:14+] "A dummy argument name in an intrinsic procedure has a scope as an argument keyword of the scoping unit making reference to it. As an argument keyword, it may appear only in a procedure reference for the procedure of which it is a dummy argument." SUBMITTED BY: Hideo Wada, IPSJ/ITSCJ SC22/Fortran HISTORY: 93-288 m127 submitted (Shepherd) 93-309r1 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000172 TITLE: Length specified for a character-valued statement function KEYWORDS: statement function, constant expression DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: In 5.1.1.5 [43:6-7] should The length specified for a character-valued statement function or statement function dummy argument of type character must be an integer constant expression. be changed to The length specified for a character-valued statement function or statement function dummy argument of type character must be a constant specification expression. ANSWER: Yes. Discussion: This text is based on FORTRAN 77 in 15.4.3 [15-6:40] The length specification of a character statement function or statement function dummy argument of type character must be an integer constant expression. In FORTRAN 77, integer constant expression, 6.1.3 and 6.1.3.1, did not allow function references while in Fortran 90 integer constant expression, 7.1.6.1, has a different definition and allows all elemental intrinsic functions and all transformational intrinsic functions [77:22-23]. Most such occurrences of integer constant expression in FORTRAN 77 were changed to specification expression in Fortran 90. This particular case was missed, resulting in an unusually broad extension of FORTRAN 77, and an inconsistency with the Fortran 90 syntax for character length specification R508 char-length is (type-parm-value) or scalar-int-literal-constant R509 type-parm-value is specification-expr or * An edit is provided to make the correction. EDIT: In 5.1.1.5 [43:6-7] change the paragraph following item (3) to: The length specified for a character-valued statement function or statement function dummy argument of type character must be a constant specification expression. SUBMITTED BY: Dick Weaver HISTORY: 94-090r1 m128 submitted 94-090r1 m128 proposed response, approved uc 94-116r1 m129 X3J3 ballot approved 23-0 N984 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000174 TITLE: Consistent definition of NCOPIES KEYWORDS: REPEAT intrinsic, SPREAD intrinsic, NCOPIES DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Consider the following two function references: REPEAT (... NCOPIES=N) SPREAD (... NCOPIES=N) Based on the definitions of REPEAT in section 13.13.87 and SPREAD in section 13.13.101, the following observations can be made. When N has a positive value: REPEAT returns the concatenation of NCOPIES of a string SPREAD returns an array, broadcasting NCOPIES of a source along a dimension When N has the value 0: REPEAT returns a zero-length string SPREAD returns a zero-sized array But, when N has the value -1, something different happens REPEAT is invalid. For repeat NCOPIES must not be negative SPREAD returns a zero-sized array. The definition of SPREAD references NCOPIES with MAX(NCOPIES,0) Thus, while uses of NCOPIES have a consistent model for both positive and zero values, the negative (out-of-range) case has introduced what would appear to be capricious differences, one an error while the other is ignored and treated as zero, thus complicating the language and astonishing the user. Should NCOPIES have a consistent definition for negative values? ANSWER: No. Discussion: As the use of NCOPIES in SPREAD is for a subscript then the returning of a zero-sized array for negative values of NCOPIES is consistent with the treatment of negative extents in array sections. Within REPEAT, NCOPIES is not used as the subscript of an array. EDITS: None SUBMITTED BY: Dick Weaver HISTORY: 94-133 m129 submitted, response supplied failed 9-14 94-133r3 m129 revised answer and deleted edits; approved 19-1. 94-221 m130 X3J3 ballot approved u.c.; accepted O'Gara edit N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000178 TITLE: Specific routine with same name as generic passed as argument KEYWORDS: argument - actual, specific name, generic name DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: If a generic interface contains a specific interface with the same name as the generic, can the procedure with the specific name be passed as an actual argument? The penultimate constraint in 12.4.1 states [172:7-8]: "A must not be the name of an internal procedure or of a statement function and must not be the generic name of a procedure (12.3.2.1, 13.1)." On the other hand, 12.4.1.2 states [173:33-34]: "If the specific name is also a generic name, only the specific procedure is associated with the dummy argument." These two statements appear to conflict. ANSWER: Yes. As indicated by 12.4.1.2, a specific procedure may appear as an actual argument even if it has the same name as a generic name. Discussion: The penultimate constraint of section 12.4.1 should have restricted a generic name from appearing as an actual argument when the generic name is not also a specific name. The constraint should not have restricted the appearance as an actual argument of a specific name that is also a generic name. As indicated by the referenced text from section 12.4.1.2, the latter case is permitted by the standard. An edit is provided to correct the constraint. The following program fragment is standard conforming SUBROUTINE TEST INTERFACE F FUNCTION F(X) REAL F, X END FUNCTION F END INTERFACE CALL THING (F) ! F is specific as well as generic END SUBROUTINE TEST REFERENCES: JOR item 50 EDIT: Section 12.4.1, insert the following in the penultimate constraint, ahead of "(12.3.2.1, 13.1)" [172:8]: "unless it is also a specific name" SUBMITTED BY: Janice C. Shepherd HISTORY: 94-157 m129 submitted with proposed response, approved u.c. 94-221 m130 X3J3 ballot, approved u.c. N984 m131 WG5 approved --------------------------------------------------------------------------------