PC File: 95-006b2.100 Archive: 95-006r2.B100 -------------------------------------------------------------------------------- NUMBER: 000100 TITLE: ASSOCIATED intrinsic and zero-sized objects KEYWORDS: ASSOCIATED intrinsic, zero-sized objects, target, pointer DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: What is the behavior of the ASSOCIATED intrinsic function for zero-sized arguments? Question 1: Can the single argument form of the ASSOCIATED intrinsic return true as its result if the argument's target is zero sized? Question 2: Can the two-argument form of the ASSOCIATED intrinsic return true when both arguments are zero sized? The following need answers only if the answer to question 2 is yes. Question 2a: If the arguments to ASSOCIATED are zero sized but of rank greater than one, must the extents of each dimension be the same for ASSOCIATED to return true? For example, what is printed by the following program? PROGRAM HUH REAL, DIMENSION(:,:), POINTER :: P1, P2 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(10:9:1, :) P2 => A(:, 10:9:1) PRINT *, ASSOCIATED (P1, P2) END Question 2b: In the following example, rank, shape, type, kind type parameters, and extent of dimensions of the zero-sized arguments to ASSOCIATED match, but the second argument is not the same as the right hand side of the previous pointer assignment statement. What is the output of this program? (Does a notion of "base address" come to play for zero-sized objects as it does for nonzero-sized objects?) PROGRAM HMMM REAL, DIMENSION(:,:), POINTER :: P1 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(:, 2:1:1) PRINT *, ASSOCIATED (P1, A(:, 3:2:1)) END ANSWERS: Answer 1: The one-argument form of ASSOCIATED returns a result of true if the pointer actual argument is currently associated with a target, even if the target is zero sized. Answer 2: No; if either argument is zero sized the result is false. The following edits clarify the intent. Answer 2a: The result is false because P1 and P2 each are zero sized. Answer 2b: The result is false because the arrays are of zero size. Discussion: The reasons for having the ASSOCIATED function return false for zero-sized arrays is based on an analogy with sharing storage and how assignment works. In normal English we understand the concept of "totally associated" and "partially associated". If two things are totally associated then doing something to one of them does the exact same thing to the other. If two things are partially associated then doing something to one of them does something to the other. Section 14.6.3.3 hints at this by discussing "totally associated" in terms of "the same storage sequence". After executing assignment statements like I = values J = different_values we would call I and J associated if it were no longer true that I == values. Zero-sized arrays are the end case where doing "something" to them is equivalent to doing nothing to them. And in the example above we would still have I == values after the assignment if both I and J were zero-sized but would otherwise appear to be associated. We could also conclude that after the pair of assignment statements above executed we would have I == different_values if I and J were zero sized, since the comparison operators return true for zero-sized objects. However, on balance it seems better to view the comparison with the initial conditions, not the potential changed conditions. As a practical matter sensible use of the ASSOCIATED function with zero-sized arrays will usually require user special casing of the results. EDITS: 1. Section 13.13.13 Case (ii) [198:37], replace by "If TARGET is present and is a target, the result is true if TARGET does not have size zero and POINTER is currently associated with TARGET. Otherwise, the result is false." 2. Section 13.13.13 Case (iii) [199:1], replace by "If TARGET is present and is a pointer, the result is true if both POINTER and TARGET are currently associated with the same nonzero-sized target. Otherwise, the result is false." SUBMITTED BY: Jon Steidel - X3J3/92-240 HISTORY: ui 114 (jw note) 92-240 m123 Submitted 93-035 m124 response, adopted by unanimous consent 93-111 m125 ballot, return to subgroup based on Hirchert, Maine comments. Also see Ellis comment for 000108 93-138r m125 revised response adopted 11-8. 93-255r1 m127 ballot passed 21-3 94-160 m129 WG5 ballot, failed 94-253r3 m130 revised response, approved u.c. 94-306 m131 X3J3 ballot, approved 15-4 95-044 m132 WG5 ballot, approved, with Reid edit -------------------------------------------------------------------------------- NUMBER: 000102 TITLE: Returned value for INQUIRE POSITION= on an empty file KEYWORDS: INQUIRE statement, i/o file position DEFECT TYPE: Interpretation STATUS: Published 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: Published 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: Published 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: Published 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: Published 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: Published 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: Published 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: Published 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: Published 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: 000121 TITLE: ";" As a Statement Separator KEYWORDS: source form - statement separator, ";" DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Are the following cases legal? (1) C = A ; + B (2) F = ; & G (3) ; P = Q The phrase "partial statements" used in sections 3.3.1.2 and 3.3.2.2 would suggest that they are legal code fragments. It was likely the intention that the semicolon be permitted after a complete statement and (possibly) before the start of a subsequent statement. ANSWER: None of the cases are conforming. Discussion: The phrase "partial statements" used in 3.3.1.2 and 3.3.2.2 was intended to describe the strictly lexical entity resulting when a line is continued in mid-statement. A statement interrupted by continuation, and the associated portion on the subsequent line, are two partial statements. Thus it was intended that breaking a statement into two partial statements be accomplished by continuation only, and not also by the ";" separator. Edits are provided to avoid the use of the phrase "partial statements" while making more concise the intention of the standard committee. With these edits, the following are conforming examples, and cases (1), (2) and (3) are nonconforming. F = & G ; P = & ! conforming Q F = & G ; P = Q ! conforming F = G ; P = & ! conforming Q EDITS: 1. Section 3.3.1.2 [22:44-45], change the first sentence to read as follows: 'The character ";" terminates a statement, except when the ";" appears in a character context or in a comment. This optional termination allows another statement to begin following the ";" on the same line. A ";" must not appear as the first nonblank character on a line.' 2. Section 3.3.1.2 [23:1-2], eliminate the last sentence of this section (it becomes redundant with edit 1). 3. Section 3.3.2.2 [23:36-37], change the first sentence to read as follows: 'The character ";" terminates a statement, except when the ";" appears in a character context, in a comment, or in character position 6. This optional termination allows another statement to begin following the ";" on the same line. A ";" must not appear as the first nonblank character on a line, except in character position 6.' 4. Section 3.3.2.2 [23:39-40], eliminate the last sentence of this section (it becomes redundant with edit 3). SUBMITTED BY: Paul St. Pierre, 119-PSP-1 HISTORY: 119-PSP-1 (initial submission) ui 94 (jw note) 92-284 m123 considered 94-072r1 m128 new response approved uc 94-116 m129 X3J3 ballot failed 13-10 94-243r1 m130 Revised 3rd edit and revised question to be closer to original question. Approved u.c. 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot, approved, accept Reid edit. -------------------------------------------------------------------------------- NUMBER: 000122 TITLE: Intrinsic procedures in modules KEYWORDS: intrinsic procedure, module DEFECT TYPE: Interpretation STATUS: Published 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: Published 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: Published 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: Published 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: Published 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: Published QUESTION: In section 11.3.2 the standard indicates that if two generic interfaces are accessible in the same scoping unit and have the same name they are interpreted as a single generic interface. How does the phrase 'the same name' apply when a generic identifier has been renamed on a USE statement? More specifically, given the following module definitions: MODULE M1 INTERFACE GEN1 SUBROUTINE S1 (I) END SUBROUTINE END INTERFACE END MODULE MODULE M2 INTERFACE GEN2 SUBROUTINE S2 (I,J) END SUBROUTINE END INTERFACE END MODULE MODULE M3 INTERFACE GEN1 SUBROUTINE S3 (I) END SUBROUTINE END INTERFACE END MODULE which of the following code fragments are standard conforming? a) USE M1, GEN => GEN1 USE M2, GEN => GEN2 b) USE M1 USE M2, GEN1 => GEN2 c) USE M1 USE M3, OTHERGEN => GEN1 ! Avoid conflict with GEN1 from M1 ANSWER: The local name of a generic interface accessed through use association is the name that is significant when determining if that generic interface has the same name as any other accessible generic interface. All three code fragments are standard conforming. Discussion: In section 14.1.2.3 rules for "Unambiguous generic procedure references" are provided. These rules "must be satisfied by every pair of specific procedures that have the same generic name". In code fragment a, the generic interface named "GEN" is interpreted as a single generic interface and subroutines S1 and S2 are specific names of that interface. The rules in 14.1.2.3 also are met. In code fragment b, because GEN2 is renamed as GEN1, it is GEN1 that is the local name of the generic interface accessed from module M2. The generic interface accessed from M1 also has local name GEN1, so the two generic interfaces are treated as a single generic interface, based on the 11.3.2 rules. In code fragment c, OTHERGEN is the local name for GEN1 accessed from module M3. GEN1 is the local name for GEN1 accessed from module M1. As these local names are not the same, the generic interfaces are not treated as a single generic interface. The sentence in section 11.3.2 that states that "If two or more generic interfaces that are accessible in a scoping unit have the same name" does not clearly state that the name is a "local" name which was the intent of the standard. An edit is provided to correct this. EDIT: The sentence in section 11.3.2 that states that if two "generic interfaces that are accessible in a scoping unit have the same name" [158:26-27], change "the same name" to "the same local name". SUBMITTED BY: Janice C. Shepherd HISTORY: 93-058 m124 Submitted 93-096 m124 Draft response 93-098 (jw note) 93-149 m125 Revised response, approved 17-1 93-255r1 m127 ballot passed 24-0 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000129 TITLE: Array constructors in initialization expressions KEYWORDS: array constructor, expression - initialization, implied-DO variable DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: It was likely the intent of the standard to allow the program fragment INTEGER ARRAY(3) PARAMETER ( ARRAY = (/ (ABS(I), I=-3,-1) /) ) However, according to the text in the second list in 7.1.6.1 "(/ (ABS(I), I=-3,-1) /)" is not an initialization expression. The array constructor "(/ ABS(-3), ABS(-2), ABS(-1) /)" qualifies as an initialization expression since item (2) in the list indicates that an array constructor is an initialization expression if each element is an initialization expression, and (4) includes "An elemental intrinsic function reference of type integer or character where each argument is an initialization expression of type integer or character" The problem with the "ABS(I)" in PARAMETER ( ARRAY = (/ (ABS(I), I=-3,- 1) /) ) is that "ABS(I)" is not defined as an initialization expression. It does not qualify under (4) as "I" is not an initialization expression and it does not qualify under (2) as the primary ABS(I) is neither an initialization expression nor an implied-DO variable. Is the program fragment standard conforming? ANSWER: Yes, the fragment was intended to be standard conforming. This is an error in the standard that is corrected by the edits below. Similar corrective edits are included for the definitions of constant and restricted expressions. EDITS: 1. In section 7.1.6.1, in the first list, in item 2 [77:20], change: "either constant expressions or implied-DO variables," to: "constant expressions," 2. In section 7.1.6.1, in the first list, in item 6 [77:28], delete the last "or" 3. In section 7.1.6.1, in the first list, add as item 7 and renumber the rest [77:28+]: "(7) An implied-DO variable within an array constructor where the bounds and strides of the corresponding implied-DO are constant expressions, or" 4. In section 7.1.6.1, in the second list, in item 2 [77:39], change: "either initialization expressions or implied-DO variables," to: "initialization expressions," 5. In section 7.1.6.1, in the second list, in item 6 [78:10], delete the last "or" 6. In section 7.1.6.1, in the second list, add as item 7 and renumber the rest [78:10+]: "(7) An implied-DO variable within an array constructor where the bounds and strides of the corresponding implied-DO are initialization expressions, or" 7. In section 7.1.6.2, in the list, in item 5 [79:4], change: "either restricted expressions or implied-DO variables," to: "restricted expressions," 8. In section 7.1.6.2, in the list, in item 9 [79:15], delete the last "or" 9. In section 7.1.6.2, in the list, add as item 10 and renumber the rest [79:15+]: "(10) An implied-DO variable within an array constructor where the bounds and strides of the corresponding implied-DO are restricted expressions, or" SUBMITTED BY: Janice C. Shepherd HISTORY: 93-027 Submitted 93-088 Draft response approved 93-111 m125 ballot approved with Martin, Rolison edits 94-160 m129 WG5 ballot, failed 94-181r2 m129 reversed response, approved u.c. 94-221 m130 X3J3 ballot failed 22-1 94-244 m130 Edits revised. Approved u.c. 94-306 m131 X3J3 ballot, approved 19-0 95-044 m132 WG5 ballot, approved -------------------------------------------------------------------------------- NUMBER: 000130 TITLE: Multiple statements on line with END statement KEYWORDS: END statement, source form DEFECT TYPE: Erratum STATUS: Published 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: Published 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: Published 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: Published QUESTION: What constitutes a token for purposes of complying with the rules for blanks in section 3.3.1 "Free source form"? Specifically, are blanks permitted on either side of the underscore in a literal constant with a kind parameter (whether or )? If the kind parameter is a name, then surely the name is a token itself and cannot be part of a literal constant token. So if a literal constant with a kind parameter is two separate tokens, can't there be blanks in there somewhere? Related question: Are blanks permitted on either side of the exponent letter in a real literal constant? ANSWER: No, in free source form, blanks are not permitted on either side of an underscore that separates a literal constant from its kind type parameter, nor are they permitted on either side of an . Discussion: Section 3.3.1 describes the general rules of free source form. The general rules for the formation of tokens, which apply to both source forms, are given in 3.2. Section 3.2 states Lexical tokens are sequences of characters with indivisible interpretations that constitute the building blocks of a program. and gives examples of lexical tokens including: ... keywords, names, literal constants other than complex literal constants, operators, labels, ... Section 3.3.1 allows blanks to occur between the tokens of a complex literal constant but blanks are not allowed within any other literal constant form because such other literal constants are, by 3.2, (indivisible) lexical tokens. EDITS: None. SUBMITTED BY: T. Lahey and M. Snyder HISTORY: 93-131r1 m125 Submitted 93-219 m126 Draft response, approved uc 93-255r1 m127 ballot passed 23-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000134 TITLE: subsumed by 000012 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: EDITS: SUBMITTED BY: Dick Weaver HISTORY: 93-155 m125 submitted 93-215r2 m126 Proposed response, adopted uc 93-255r1 m127 ballot failed 22-2 m127 subsumed by 000012 -------------------------------------------------------------------------------- NUMBER: 000135 TITLE: INTENT(IN) conformance KEYWORDS: INTENT(IN) attribute, conformance DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 1.4, Conformance, states "An executable program (2.2.1) is a standard-conforming program if it uses only those forms and relationships described herein and if the executable program has an interpretation according to this International Standard." Consider the following fragment: SUBROUTINE A (X) INTENT(IN) :: X IF (expr) X = 1.0 The intent attribute (5.1.2.3) specifies that X must not be redefined or become undefined during the execution of the procedure. Does the use of X in this fragment meet both conformance requirements -- using only those forms and relationships described herein -- the executable program has an interpretation (assume that "expr" is false) according to this International Standard? If "yes", was it the intent of the standard that a conforming processor not reject this program until X=1.0 is executed? ANSWER: No, the use of X in this fragment does not meet the conformance requirements of using only forms and relationships described in the standard. However, the existing wording of the standard could be interpreted to imply that the fragment was conforming if "expr" were always false. The edits below clarify that the fragment is non-conforming whether or not "X=1.0" is executed, and apply equally to the INTENT attribute in a type declaration statement and the INTENT statement. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.2.1 and 14.7.5 EDITS: 1. Section 5.1.2.3 following R511 - add the following constraint after the existing constraint [44:24+]: "Constraint: A dummy argument with the INTENT(IN) attribute, or subobject of such a dummy argument, must not appear (1) As the of an , (2) As a DO variable or implied-DO variable, (3) As an in a , (4) As a in a if the appears in a NML= specifier in a , (5) As an in an , (6) As an IOSTAT= or SIZE= specifier in an input/output statement, (7) As an inquiry specifier variable in an INQUIRE statement, (8) As a in an or , (9) As an actual argument in a reference to a procedure with an explicit interface when the associated dummy argument has the INTENT(OUT) or INTENT(INOUT) attribute, or <<(10) In an .>>" SUBMITTED BY: Dick Weaver HISTORY: 93-156 m125 initial submission 93-191 m126 proposed response 93-208 m126 revised response, approved uc 93-255r1 m127 ballot failed 21-3 93-326 m127 response approved uc 94-034 m128 X3J3 ballot failed 25-2 94-091 m128 additional edit supplied, approved 16-1 94-116 m129 X3J3 ballot failed 10-13 94-274r1 m130 Revised response, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot, approved, with edits -------------------------------------------------------------------------------- NUMBER: 000136 TITLE: scalar-structure-component in data-implied-do KEYWORDS: DATA statement DEFECT TYPE: Erratum STATUS: Published 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: 000137 TITLE: array-element in data-implied-do KEYWORDS: DATA statement DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: R536 states that an can be a . 5.2.9, first paragraph following the constraint, states "A variable ... must not be initialized more than once in an executable program." Thus (A(2), I = 1,1) is conforming while (A(2), I = 1,2) is not conforming Is there a constraint missing, along the lines of s and s that are s must each have at least one subscript whose value is a function of the . ANSWER: No. There is no constraint missing. Discussion: The first implied-DO was standard conforming in FORTRAN 77, and continues to be in Fortran 90. EDIT: None SUBMITTED BY: Dick Weaver HISTORY: 93-158 m125 submitted 94-046r1 m128 response approved 10-4 94-116 m129 X3J3 ballot failed 12-11 94-291 m130 alternate response, approved u.c. 94-306 m131 X3J3 ballot approved 18-1 95-044 m132 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000138 TITLE: PRIVATE accessibility of a MODULE PROCEDURE KEYWORDS: PRIVATE attribute, module procedure DEFECT TYPE: Interpretation STATUS: Published 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: 000139 TITLE: INTRINSIC, EXTERNAL attribute questions KEYWORDS : INTRINSIC attribute, EXTERNAL attribute, conformance DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 5.1.2.11 "INTRINSIC attribute" states The INTRINSIC attribute specifies that an object name in a declaration containing this attribute must be the specific or generic name of an intrinsic function... Section 5.1.2.10 "EXTERNAL attribute" has similar wording Question 1: Given REAL, INTRINSIC :: SIN REAL, EXTERNAL :: ABC Are SIN and ABC object names? If so, of what objects? Question 2: Given LOGICAL, INTRINSIC :: SIN What entity is being declared with the type 'LOGICAL'? ANSWER: Answer 1: SIN and ABC are not object names. The standard should not have used 'object name' in sections 5.1.2.10 and 5.1.2.11, but the name of the appropriate syntactic class. The edits below correct these sections. Answer 2: No entity is being declared with the type LOGICAL. Specifying a data type for a generic intrinsic function does not, in itself, remove the generic property from that function (section 5.1, [40:36-38]). There is no requirement for the data type specified in such a case to be one of the return types of the generic intrinsic. REFERENCES: 93-006R 000066 EDITS: 1. Section 5.1.2.10 Replace 'an object name' with 'a function name' [48:26] 2. Section 5.1.2.11 Replace 'an object name' with 'a function name' [48:30] SUBMITTED BY: Dick Weaver X3J3/93-160 HISTORY: 93-160 m125 Submitted 93-183 m125 response withdrawn 93-314r1 m127 response withdrawn 94-209 m129 minor changes to response, failed 9-10 Current version is 93-314r1. 3rd and 4th edits should be dropped. 94-292 m130 reversed answer 2 and reduced to 2 edits; approved u.c. 94-306 m131 X3J3 ballot approved 18-1 95-044 m132 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000142 TITLE: Namelist I/O KEYWORDS: i/o namelist, derived type, use association, PRIVATE attribute, use renaming DEFECT TYPE: Erratum STATUS: Published 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: 000143 TITLE: Use association and functions/subroutines/intrinsics KEYWORDS: use association, function, type declaration, subroutine, intrinsic procedure, external procedure DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: In Fortran programs it is sometimes the way an entity is referenced that partially determines what the entity is. For example given the following specification section: INTEGER X it is not clear until X is referenced as to whether X is the name of a function or the name of a variable. If such a specification statement appears in the scope of a module, can a reference to the entity by use association partially determine what the entity is? Section 11.3.2 indicates that the local name of an entity made accessible by use association may appear in no other specification that would cause any attribute of the entity to be respecified in the scoping unit (except the local name can appear in a PUBLIC or PRIVATE statement if the scoping unit is a module). But this section does not comment on the following example: MODULE M1 IMPLICIT INTEGER(A) INTEGER UNCLEAR1, UNCLEAR2 EXTERNAL ALSO_UNCLEAR ! Could be a subroutine or a function INTEGER SIN ! Could be a variable or an intrinsic CONTAINS SUBROUTINE XX(I) I = UNCLEAR1() ! Indicates UNCLEAR1 ! is a function not a variable. END SUBROUTINE END MODULE USE M1 WRITE(6,*) UNCLEAR1(), UNCLEAR2(), ALSO_UNCLEAR() END ANSWER: No. Discussion: The text of 11.3.2 cited addresses attributes being specified in specification statements. The text however does not consider the classification of a procedure as a function or a subroutine as this can be specified by executable statements. It was the intent that attributes of all use associated entities and the classification of use associated procedures be specified within the scope of the module. An exception was made for the PUBLIC and PRIVATE attributes. An edit is provided to clarify the intent. EDIT: In section 11.3.2, ahead of "Examples:" add 2 new paragraphs [158:41+]: "A procedure with an implicit interface and public accessibility must explicitly be given the EXTERNAL attribute in the scoping unit of the module; if it is a function, its type and type parameters must be explicitly declared in a type declaration statement in that scoping unit. An intrinsic procedure with public accessibility must explicitly be given the INTRINSIC attribute in the scoping unit of the module or be used as an intrinsic procedure in that scoping unit." SUBMITTED BY: Janice C. Shepherd HISTORY: 93-190 m126 submitted 93-316 m127 response approved uc 94-034 m128 X3J3 ballot failed 22-6 94-242r1 m130 revised text and edit; approved u.c. 94-306 m131 X3J3 ballot approved 18-1 95-044 m132 WG5 ballot approved, with Reid edit -------------------------------------------------------------------------------- NUMBER: 000144 TITLE: Specification expressions and implicit typing. KEYWORDS: expression - specification, implicit typing, host association DEFECT TYPE: Interpretation STATUS: Published 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: 000147 TITLE: Generic name resolution KEYWORDS: generic name DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Consider the following program: PROGRAM EX1 INTERFACE SQRT REAL FUNCTION USERSQRT(I) INTEGER I END FUNCTION USERSQRT END INTERFACE CALL TEST CONTAINS SUBROUTINE TEST INTRINSIC SQRT WRITE(*,*) SQRT(16) END SUBROUTINE TEST END According to the standard (section 14.1.2.4) the name SQRT is both generic in TEST (since it is a generic intrinsic) and in the host scope EX1 since it is a generic user procedure. According to 14.1.2.4.1 the reference to SQRT(16) should resolve to USERSQRT; i.e. even though the user specifies intrinsic for SQRT the user ends up with a reference to a user procedure. Contrast that with the following example where SQRT has been replaced by CSQRT: PROGRAM EX2 INTERFACE CSQRT COMPLEX FUNCTION USERSQRT(I) INTEGER I END FUNCTION USERSQRT END INTERFACE CALL TEST CONTAINS SUBROUTINE TEST INTRINSIC CSQRT WRITE(*,*) CSQRT(16) END SUBROUTINE TEST END In this case CSQRT is the name of a specific intrinsic procedure and the reference CSQRT(16), is according to 14.1.2.4.2 to that procedure, which since the argument type is integer, is invalid. By changing from a generic to a specific intrinsic name, the call resolution changes drastically which a user could find very confusing - it seems that the INTRINSIC attribute confers different properties in the two cases. Is this interpretation of the standard correct? If so, was this the intended behavior? ANSWER: Yes, the interpretation of the standard is correct. Yes, it was the intended behavior. Discussion: In the first example, SQRT is established to be a generic name. The resolution of a reference to a generic name is specified in 14.1.2.4. In the second example, CSQRT is established to be a specific intrinsic name within the internal procedure. In a reference to a specific intrinsic, any arguments specified must match those expected by the specific intrinsic. EDITS: None. SUBMITTED BY: Graham Barber HISTORY: 93-202 m126 submitted 94-294 m130 response approved u.c. 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot approved, with Shepherd edit --------------------------------------------------------------------------------