J3/00-006r1 Date: 03 Jul 2000 To: J3 From: Stan Whitlock Subject: F95 interpretations document Fortran 95 Interpretations Table of Contents Part 0 contains the summary status of all of the Fortran 95 interpretations Part 1 contains the interpretation processing rules from 00-142. Part 2 contains F95 interpretation 000000e (typographical interps), interpretations 1-32 (00-126) and 66-85 (00-126). Part 3 contains the remaining F90 interpretations left over, with their F90 interp numbers (prefixed with "F90/"). Exceptions: 000200 was already subsumed by 000202 and so does not appear. 000202 was replaced by F95/000012 at meeting 143. Note: F90/000202 history added to F95/000012 history. Note: Additionally to those noted in 00-126, F90 interps 000206-000212 are included Part 4 contains the Japanese interpretations with their japanese numbers (JP-4 etc.). ---------------------------------------------------------------------- ====================================================================== Part 0: Summary Status of these Fortran 95 Interpretations ====================================================================== Status S: Defect Type T: P == J3 consideration in progress C == Clarification M Passed by J3 meeting E Erratum B Passed by J3 letter ballot I Interpretation W Passed by WG5 ballot C Included in corrigendum S T number title - - ------ ----- P I 000000e Rejected Minor edits and corrections M I 000001 Visibility of a data object with statement scope P I 000002 Free source form requirement for blank in PRINT statement M I 000003 Ability to overload the character operator // M I 000004 Value returned by MAXVAL/MINVAL P I 000005 Value returned by SELECTED_REAL_KIND P I 000006 Character length specification of a function result P I 000007 Optional intrinsic function arguments P I 000008 Optional arguments to MAX/MIN P I 000009 INTENT of MOLD argument to TRANSFER P I 000010 Meaning of embedded blanks in namelist input name P E 000011 G editing typo P I 000012 Evaluation of Intrinsic Procedures P 000013 Format of zero in list-directed and namelist output P 000014 Format of complex numbers in list-directed and namelist output P 000015 Commas in list-directed output * 000016 Character array constructors {duplicated by 000071} P I 000017 Characteristics of an array function result P 000018 ELEMENTAL procedures with no arguments P 000019 Result of NULL intrinsic associated with CHARACTER(*) dummy argument P 000020 Execution of a WHERE statement within a WHERE construct P 000021 Restrictions on on END INTERFACE P 000022 Use of NULL() as initialization P 000023 Termination of the previous record by a WRITE statement P 000024 Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement P 000025 List-directed input: types of variables corresponding to repeated values P 000026 List-directed input: types of variables corresponding to repeated values P 000027 Sequential formatted I/O: position of the left tab P C 000028 Implicitly Typed Statement Function Character Dummy M E 000029 Association of a pointer actual argument with a dummy argument P 000030 Ordering requirements on definition of specification functions P 000031 Association of pointer function result with INTENT(OUT) dummy argument P 000032 Is the TRANSFER function result undefined? M E 000066 Errors in processing data transfer statements B E 000067 Writing zeros B E 000068 Asterisks as I/O units B E 000069 What is a numeric character? B E 000070 Asymmetry between constant specification and initialization expressions B E 000071 Character array constructors B E 000072 Resolving generic procedure references P 000073 Is padding allowed in storage sequences? P 000074 TARGET dummy arguments and POINTER expressions P 000075 Defined assignment and INTENT(IN) dummy arguments in PURE procedures B E 000076 INTENT(IN) dummy arguments and implied DO loops B E 000077 INTENT(IN) dummy arguments and NULLIFY P 000078 Resolving generic procedure references B E 000079 Pointer Assignment and Allocatable Arrays B E 000080 Host association and the EXTERNAL attribute P 000081 Definition status of derived-type objects with pointer components B E 000082 Usage of BOZ literal constants B E 000083 Scope of array-constructor implied-DO variable B E 000084 Events that cause variables to be defined P 000085 Public components of private types P I F90/000049 Characteristics of function results P E F90/000070 Characteristics specified by interface bodies P E F90/000096 Definition of "Declaration" B I F90/000100 ASSOCIATED intrinsic and zero-sized objects ??STATUS: J3 approved; ready for WG5 P E F90/000140 TARGET attribute for a derived-type object with a pointer component P E F90/000145 Expressions in of a FUNCTION statement P F90/000164 Use of ONLY with multipart definitions B I F90/000179 DO variable with POINTER attribute ??STATUS: J3 approved; ready for WG5 P E F90/000180 Unambiguous generic references B I F90/000185 What is the allocation status of an array after an allocation failure? ??STATUS: J3 approved; ready for WG5 P I F90/000190 Subobjects of constants in a DATA statement P E F90/000191 Interaction of SEQUENCE derived types and rename B I F90/000194 Statements between SELECT CASE and CASE ??STATUS: J3 approved; ready for WG5 P E F90/000196 Inaccessibility of intrinsic procedures P F90/000197 Relationship of NEAREST and SPACING P F90/000204 Meaning of "same variable" description of MVBITS P F90/000205 Restrictions on EXTERNAL P F90/000206 Collating sequence inconsistencies P F90/000207 Integer bit-model inconsistency P F90/000208 nonadvancing output followed by list directed output P F90/000209 STOP|PAUSE in I/O statement P F90/000210 nonadvancing write followed by list directed write P F90/000211 Multiple MODULE PROCEDURE specs P F90/000212 EQUIVALENCE of Data Objects of Different Types or Kinds P JP-4 Construction of derived-type values P JP-5 Construction of array values P JP-6 Type declaration statements P JP-8 Type declaration statements P JP-12 Bounds of each dimension of an array pointer P JP-16 Multiple occurrence of namelist-group-name in NAMELIST statement P JP-17 Multiple occurrence of namelist group object in namelist group P JP-24 The bnf term shared-term-do-construct P JP-31 Signs of literal constants P JP-39 Note 12.20 ---------------------------------------------------------------------- ====================================================================== Part 1: Interpretation Processing Rules ====================================================================== 0. All interpretations are listed in J3 standing document 006. 1. Interpretations are processed by the J3/interp group and given a number. The interpretation is marked "J3 consideration in progress". An answer is formulated and presented to J3 in a meeting paper. 2. J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". 3. Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 4. The chair of J3/interp gathers all interp answers that are marked "passed by J3 letter ballot" and forwards them to the WG5 convenor. The WG5 convenor holds a ballot of individual members; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. The answers that pass this ballot become "WG5 approved". J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 5. "WG5 approved" answers are processed into a corrigendum document by taking the edits from the interp answers and putting them in the format required by ISO. A WG5 vote is made on forwarding the corrigendum to SC22. Interps so forwarded are marked "Corrigendum". 6. J3/interp creates a edit for F2K if one is needed for all interps marked "Corrigendum". ---------------------------------------------------------------------- ====================================================================== Part 2: Correctly numbered F95 interpretations ====================================================================== NUMBER: 00000e TITLE: Rejected Minor edits and corrections KEYWORDS: typographical errors DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Should the following be added to the list of edits? 8. In 13.13.85 RANGE change 'Returns the decimal exponent range in the model ...' to 'Returns the upper bound of the decimal exponent range of the model ...' [228:20] Rationale(1): a range has two values; RANGE returns only one. Rationale(2): there is not a decimal range in the model, see 13.7.1, but a decimal range can be calculated. Thus the change from 'in' to 'of'. 9. In 13.13.79 PRECISION change 'Returns the decimal precision in the model ...' to '............................. of .............' [226:4] Rationale: same as for RANGE, above. ANSWER: This item collects failed "minor edits and corrections" so that the reasons for failing them can be recorded for historical purposes. No further voting is needed for items in this list. No, 8 and 9 should not be added. The use of 'range' is consistent with other uses in the standard and is meant to convey an entire range of values not just 2. The change from 'in' to 'of' is too small a change to be included at this time and would best be addressed in a future standard. EDITS: None SUBMITTED BY: HISTORY: 94-028 m128 additional items 8-9 ---------------------------------------------------------------------- NUMBER: 000001 TITLE: Visibility of a data object with statement scope KEYWORDS: visibility, data object, statement scope, scope DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Part 1: Consider the following program: MODULE mod INTEGER, PARAMETER :: jmin(1:10) = (/ (i, i = 1, 10) /) END MODULE PROGRAM main USE mod INTEGER :: i DO i = 1, 10 PRINT *, 'jmin(i) = ', jmin(i) END DO END PROGRAM Some Fortran compilers consider the implied-DO variable I used in the module to be visible to program units using the module and some Fortran compilers do not consider the I to be visible to using program units. Is an entity with statement scope in the specification part of a module visible to a program unit using the module and accessing the public data of the module as exemplified by the above example? Part 2: Consider the adaptation of the example program from Part 1: MODULE mod INTEGER, PARAMETER :: jmin(1:10) = (/ (i, i = 1, 10) /) CONTAINS SUBROUTINE one i = 99 ! Is this a local or module variable? ! Compilers that export I probably say module END SUBROUTINE SUBROUTINE two PRINT *, i END SUBROUTINE END MODULE The module specification part uses the variable I as an implied-DO variable of an array constructor. Module procedure ONE sets a variable named I to a value. Given: * An implicitly declared data object in the module specification part where the variable has statement scope, and * An implicitly declared variable in a module procedure where the variable has the same name as the variable described in the first bullet of this list is the variable in the module procedure a module variable (known to the entire module and thus available outside the module) or is the variable local to the module procedure? ANSWER: The implied-DO variable is not visible to the using program. 14.1.3 Statement Entities states, in part, that The name of a variable that appears as the DO variable of an implied-DO in a DATA statement or an array constructor has a scope of the implied-DO list. It has the type and type parameter that it would have if it were the name of a variable in the scoping unit that includes the DATA statement or array constructor and this type must be integer. The words "would have if it were" were intended to convey the idea that the existence of an array constructor or data implied-DO variable does not actually cause an associated variable in the scoping unit to come into existence. Also, the following text appears in the same section (281:12-14): If the name of a global or local entity accessible in the scoping unit of a statement is the same as the name of a statement entity in that statement, the name is interpreted within the scope of the statement entity as that of the statement entity. The word "If" here implies that there need not be any such global or local entity with the same name as that of the statement entity. The first edit makes this clear. The second edit makes the same point for FORALL statements and constructs. EDITS: Page 280, Clause 14.1.3, at the end of the first paragragh (280:44) add: The appearance of a name as the DO variable of an implied-DO in a DATA statement or an array constructor is not an implicit declaration of a variable whose scope is the scoping unit that contains the statement. Page 281, Clause 14.1.3, at the end of the second paragraph [281:4] add: The appearance of a name as an index-name in a FORALL statement or FORALL construct is not an implicit declaration of a variable whose scope is the scoping unit that contains the statement or construct. SUBMITTED BY: Larry Rolison HISTORY: 97-237 m143 submitted 00-158 m153 passed unanimously ---------------------------------------------------------------------- NUMBER: 000002 TITLE: Free source form requirement for blank in PRINT statement KEYWORDS: Free source form, PRINT, blank DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Consider the following PRINT statement form: PRINT"(I5)",5 Section 3.3.1 of the Fortran 95 standard states: A blank shall be used to separate names, constants, or labels from adjacent keywords, names, constants, or labels. NOTE 3.3 For example, the blank[s] after ... READ ... [is] required in the following: ... READ 10 ... Although the sentence preceding R420 is somewhat confusing in that it uses the phrase "a sequence of characters, DELIMITED by either apostrophes or quotation marks", the syntax rule itself is clear that the " or ' delimiting characters are part of the syntax. The first sentence on the top of page 36 then clarifies that although the delimiter characters are a part of the syntax, they are not a part of the value. Section 3.2 makes it clear that a character literal constant is a token. Section 3.2.5 describes delimiters but does not include either " or ' because it is describing delimiters for lists. Thus, it seems clear that in free source form a blank is required between the keyword PRINT and the character literal constant containing the format list but there is also some disagreement on this point among existing Fortran processors. (1) In free source form, is a blank required between the keyword PRINT and the character literal constant containing the format specification? (2) Also, for clarification, in free source form, is a blank required between the keyword PRINT and the asterisk that represents the list-directed output specifier? ANSWER: (1) Yes. The analysis in the QUESTION is correct. Since PRINT is a keyword, when the format specification is a character literal constant, the blank is required between the keyword PRINT and the format specifier. (2) No. Since PRINT is a keyword, according to the cited rule in 3.3.1, the asterisk would have to be a name, a constant, or a label in order for a blank to be required to separate PRINT from the asterisk. By 3.2.1, an asterisk is not a name. By 3.2.2, an asterisk is not a constant. And by 3.2.4, an asterisk is not a statement label. Yes, an asterisk may be used as a dummy argument alternate return specifier representing a statement label but that usage is irrelevant to the PRINT statement. Therefore, since an asterisk is none of the three items that must be separated from PRINT by a blank, the blank is not required. EDITS: None. SUBMITTED BY: Larry Rolison / Dick Hendrickson HISTORY: J3/97-238 M143 submitted ---------------------------------------------------------------------- NUMBER: 000003 TITLE: Ability to overload the character operator // KEYWORDS: overload, intrinsic, // DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: On page 89 of the Fortran 95 standard, the Note at the bottom of Table 7.1 states in part: For the intrinsic operators REQUIRING {emphasis not in standard} operands of type character, the kind type parameters of the operands shall be the same. Since there is only one intrinsic operator (//) that REQUIRES its operands to be of type character, one may conclude that the operands of the // operator MUST be of type character and MUST have the same kind type parameters. The last sentence of the first full paragraph on page 90 restates the above rule for intrinsic uses of // as follows: For the character intrinsic operator //, the kind type parameters shall be the same. Contrast this with the last sentence of the last paragraph of this section: A {character relational intrinsic operation} is a relational intrinsic operation where the operands are of type character and have the same kind type parameter value. From the wording of this last sentence, one may conclude that if the kind type parameters are the same, then the relational operation is intrinsic but if the kind type parameters are NOT the same, then the relational operation is NOT intrinsic and must be defined via a user-provided function. Thus, it is possible for the character operands of a relational operator to have differing kind type parameter values. Now compare this to the following sentence from 7.1.4.2: For an expression // where and are of type character, the character length parameter is the sum of the lengths of the operands and the kind type parameter is the kind type parameter of , which shall be the same as the kind type parameter of . Note that there is no text or title to indicate that the description is only for intrinsic operators. There appears to be no way to overload the // symbol at all since the wording does not restrict the rule to the intrinsic interpretation of the operator (it appears in fact from the wording that once the operands are of type character, there can be no other interpretation other than intrinsic). This is surely not what was intended. The wording should be redone to more closely resemble that for the character relational operators such that if the operands of // do not have the same kind type parameters, an overload is allowed (and the operator is not interpreted as being intrinsic). (See also 7.2.2 Character intrinsic operation.) ANSWER: Intrinsic concatenation is defined only for character operands with the same kind type parameter value. This is stated clearly (90: 8-9): 'For the character intrinsic operator //, the kind type parameters shall be the same'. There is a need for a similar restriction at this point for relational intrinsic operators with character operands. The words at the end of the next paragraph (90: 12) actually suggest that there are relational intrinsic operations for character operands of different kind type parameter values that are not character relational intrinsic operations. The word 'requiring' in the last sentence in the note in Table 7.1 should be changed since all the intrinsic operators with character operands require their operands to have the same kind type parameter value. EDITS: Page 89, Table 7.1, penultimate line (89:38). Change 'requiring' to 'with'. Page 90, line 9. Add 'For the relational intrinsic operators with character operands, the kind type parameters shall be the same'. Page 90, line 12. Delete 'and have the same kind type parameter value'. SUBMITTED BY: Larry Rolison HISTORY: 97-239 m143 submitted 00-159 m153 passed unanimously ---------------------------------------------------------------------- NUMBER: 000004 TITLE: Value returned by MAXVAL/MINVAL KEYWORDS: MAXVAL, MINVAL DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: The Result Value section of the MAXVAL intrinsic function description uses the phrasing: or has the value of the negative number of the largest magnitude supported by the processor for numbers of the type and kind type parameter of ARRAY if ARRAY has size zero This phrasing has generated at least the two following views on the return value: * If the machine supports the IEEE standard then the implementation should return -inf. * For portability, the implementation should return -HUGE(ARRAY). These views lead to the following questions: 1. Is the intent of the standard to describe the result in terms of machine values rather than model values? 2. If the answer to 1 is "yes", how are programmers expected to use this intrinsic function portably? ANSWER: 1. Yes. Processors may support values that are not present in the model of 13.7.1. IEEE -inf is an example of such a number and this may be returned on a machine that supports the IEEE standard. If the negative number of the largest magnitude in the model had been intended, the model would have been mentioned as, for example, in the definition of HUGE (13.14.39). 2. A simple example of its use is to test whether a set of numbers SET1 has a value greater than any value in the set SET2. Consider the expression MAXVAL (SET1) > MAXVAL (SET2). If SET1 is empty and SET2 is not, this value is correctly false even if all of the values are outside the model with values less than -HUGE (SET1). It may be helpful to consider how MAXVAL might be coded for an array of rank one on an IEEE computer. The following code is suitable. MAXVAL = IEEE_VALUE ( 1.0, IEEE_NEGATIVE_INF) DO I = 1, SIZE (ARRAY) MAXVAL = MAX (MAXVAL, ARRAY(I)) END DO All of the reduction functions (e.g., MAXVAL, SUM) return values when the arguments are zero-sized arrays that may be the same as the values returned for some non-zero-sized arguments. EDITS: None. SUBMITTED BY: Larry Rolison HISTORY: 97-240 m143 submitted 00-160r2 m153 Passed 7-5 ---------------------------------------------------------------------- NUMBER: 000005 TITLE: Value returned by SELECTED_REAL_KIND KEYWORDS: SELECTED_REAL_KIND DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: The SELECTED_REAL_KIND intrinsic function does not appear to cover one specific case for real data types. Consider the following precisions and ranges for a particular model: KIND TYPE PRECISION RANGE 4 6 37 8 15 307 16 31 291 A test case for a system with this model is: PRINT *, 'selrealkind(31,291) = ', SELECTED_REAL_KIND(P=31,R=291) PRINT *, 'selrealkind(31,292) = ', SELECTED_REAL_KIND(P=31,R=292) PRINT *, 'selrealkind(32,291) = ', SELECTED_REAL_KIND(P=32,R=291) PRINT *, 'selrealkind(32,292) = ', SELECTED_REAL_KIND(P=32,R=292) END The Result Value section of the description of SELECTED_REAL_KIND clearly describes the result value when the values of P and R are within the ranges specified for the given implementation of the real data type model. It further describes the values to be returned by SELECTED_REAL_KIND when a value of P or R is not within the range of model numbers specified by the implementation. From the text in the Result Value section, the following may be determined: * The reference to SELECTED_REAL_KIND(P=31,R=291) (first PRINT line) should return the (kind type parameter) value 16. * The third and fourth SELECTED_REAL_KIND references should return -1 since the PRECISION argument is outside the set of allowed precision values. However, the value returned by the second reference to SELECTED_REAL_KIND is unknown since it does not appear to be covered by the wording of the Result Value paragraph of section 13.14.95. 1. What should the processor return for the value of the SELECTED_REAL_KIND intrinsic function when it does not have a single data type that satisfies both the P and R values? 2. In particular, given the precision and range values shown above, what should the processor return for the last three invocations of the SELECTED_REAL_KIND intrinsic function? ANSWER: The intention is that the value -1 be returned if the range can be supported but the precision cannot, the value -2 be returned if the precision can be supported but the range cannot, and the value -3 be returned if neither the precision nor the range can be supported. Provision needs to be made for the case where each can be supported, but not in combination. With the edit below, the returned values for the four invocations will be 16, -4, -1, -1. EDITS: Page 266, Clause 13.14.95, lines 11-14 (266: 26-29). Replace 'the result is -1 ... is supported.' by 'the result is -1 if the processor does not support a real data type with a precision greater than or equal to P but does support a real data type with an exponent range greater than or equal to R, -2 if the processor does not support a real data type with an exponent range greater than or equal to R but does support a real data type with a precision greater than or equal to P, -3 if the processor supports no real data type with either of these properties, and -4 if the processor supports real data types for each separately but not together.' SUBMITTED BY: Larry Rolison / Joanne Brixius HISTORY: 97-241 m143 submitted 00-161 m153 Passed unanimously as amended ---------------------------------------------------------------------- NUMBER: 000006 TITLE: Character length specification of a function result KEYWORDS: character, function result DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Consider the following program: PROGRAM main CHARACTER(8) arg, func EXTERNAL func CALL sub(arg, func) END PROGRAM SUBROUTINE sub(arg, func) CHARACTER(*) arg, func CHARACTER(8) str str = func(arg) ... END SUBROUTINE CHARACTER(8) FUNCTION func(arg) CHARACTER(*) arg ... END FUNCTION Some implementations error the reference to FUNC in subroutine SUB and some do not. The implementations that do not error the reference to FUNC use essentially the following as the argument for allowing the reference: The rules for when an asterisk can be used to specify character length are specified on in section 5.1.1.5 (middle of page 51 of the Fortran 95 standard). * The first rule states that an asterisk may be used to declare a dummy argument of a procedure. It is clear that FUNC is a dummy argument of SUB. * The third rule says that in an external function, the length of the result may be specified within the function itself with an asterisk but if the result length is so specified, any invoker of the function must specify the character length of the function result as something other than an asterisk. But the function that is being invoked in the above example does not declare its result length using the asterisk, so this rule does not apply. Is the above sample program a standard conforming program with respect to the concept of declaring the function result length in the invoking program as an asterisk? ANSWER: EDITS: SUBMITTED BY: Larry Rolison HISTORY: J3/97-242 m143 submitted ---------------------------------------------------------------------- NUMBER: 000007 TITLE: Optional intrinsic function arguments KEYWORDS: intrinsic function, argument - optional DEFECT TYPE: Interpretation STATUS: J3 consideration in progress BACKGROUND: Interpretation request 000053 asked the following question: QUESTION: Should constraining text be added to the description of optional argument Y in CMPLX, and optional argument BACK in INDEX, and optional argument SIZE in ISHFTC, and optional argument A3,... in MAX, and optional argument A3,... in MIN, and optional argument BACK in SCAN, and optional argument BACK in VERIFY to state that the argument must not be an optional argument of an invoking procedure? and it was answered as follows: ANSWER: In principle yes; however it is more appropriate to add an additional restriction on dummy arguments not present in section 12.5.2.8. Discussion: The standard contains numerous restrictions intended to ensure that the rank of a given expression never changes. The case of elemental functions with optional arguments was inadvertently overlooked. Consider the following subprogram: SUBROUTINE SUB (A,B,C) INTEGER :: A ,B INTEGER, OPTIONAL :: C (:) PRINT *, MAX (A, B, C) END When C is present, the result of the elemental function MAX, is an array of the same shape as C. However, if SUB were to be called with the third argument omitted, the result would be a scalar. The supplied edit remedies this deficiency. Corrigendum 1 then edited the Fortran 90 standard as follows: EDITS: 1. Add the following point to the numbered list in section 12.5.2.8: [179:38] (5) If it is an array, it must not be supplied as an actual argument to an elemental procedure unless an array of the same rank is supplied as an actual argument corresponding to a nonoptional dummy argument of that elemental procedure. 2. In the paragraph following the numbered list, replace "It" with "Except as noted in (5) above, it" [179:39] Corrigendum 3 modified the above edit as follows as part of the response to Interpretation request 000193: EDITS: 1. In Section 12.5.2.8, add the following to the numbered list after the list item added by Corrigendum 1 [179:38+]: "(6) If it is a pointer, it must not be supplied as an actual argument corresponding to a nonpointer dummy argument other than as the argument of the PRESENT intrinsic function." 2. In Section 12.5.2.8, in the text added by Corrigendum 1 to the last sentence of the section [179:39]: change "in (5)" to "in the list" The text as modified appears at the end of 12.4.1.5 on page 203 of the Fortran 95 standard. QUESTION: While the response to interpretation request 000053 stated "in principle" that an optional dummy argument should not be passed to an optional argument of a called procedure, and it closed a "loophole" for optional array dummy arguments, it still did not address the simpler case of an optional scalar dummy argument being passed to the cited intrinsics. Consider the following example: SUBROUTINE sub(string, substring, direction) CHARACTER(*) :: string, substring LOGICAL, OPTIONAL :: direction k = INDEX(string, substring, direction) ... END SUBROUTINE The last paragraph of 12.4.1.5 states: Except as noted in the list above, it may be supplied as an actual argument corresponding to an optional dummy argument, which is then also considered not to be associated with an actual argument. The only case in "the list above" that is relevant is (1) because DIRECTION is a dummy data object and is not an array or pointer. But (1) does not apply because the appearance of DIRECTION as an actual argument is not a reference by the following from 2.5.5: The appearance of a data object name, data subobject designator, or procedure name in an actual argument list does not constitute a reference to that data object, data subobject, or procedure unless such a reference is necessary to complete the specification of the actual argument. The appearance of DIRECTION is not "necessary to complete the specification of" DIRECTION, so therefore it is not a reference so therefore (1) does not apply. Thus, the last paragraph of 12.4.1.5 does seem to apply which indicates that an optional dummy argument can be passed to an optional argument of an intrinsic procedure such as INDEX. However, this does not seem to agree with the "principle" espoused in the answer to interpretation request 000053, nor does the description of INDEX seem to indicate how the result is to be determined if the BACK argument is specified but is not present. (One could possibly construe the phrase "If BACK is absent" to mean "specified but not present" but that does not seem to be the intent of the existing wording or the "principle" espoused in interpretation request 000053.) For an intrinsic procedure that has an optional argument, may an optional dummy argument be passed to the optional argument of the intrinsic procedure? ANSWER: EDITS: SUBMITTED BY: Larry Rolison HISTORY: J3/97-243 m143 submitted Addendum: A history of how this interp progressed: Yukimasa Yoshida sent a message to the interpretation request bulletin board noting that some of the actual arguments to intrinsic functions should not be allowed to be optional dummy arguments. Since I could not find an interpretation request in the premeeting papers for meeting 121, I submitted paper X3J3/92-058 (121-LRR-5) with his message and added that the ISHFTC intrinsic function should be added to the list supplied by Mr. Yoshida. Given the hand-written notes on my paper copy of 92-058, the /PROC subgroup apparently worked on my original paper and recast it as 92-094 with the proposed edit: The restriction: "The corresponding actual argument must not be an optional dummy argument." should be added to the text describing these optional arguments mentioned above for CMPLX, INDEX, ISHFTC, MAX, MIN, SCAN, and VERIFY. [ Historical aside: While looking through the minutes for this meeting, I noticed that this was the meeting where Richard Maine joined the committee and Walt rejoined the committee (to work on a validation suite for Fortran 90). Under Reports and Comments from Members, Andrew Tait expressed concern about the copyright situation. Some topics just never die, do they? Mind you, meeting 121 was in May, 1992. ] The minutes for the last day of the meeting show that Hirchert/Hoffert moved to adopt 92-094, but that it and several others were withdrawn. There are notes as to why some of the others were withdrawn but not for 92-094. I have no personal notes from this meeting as I did not attend. WG5 paper N786A authored by John Reid is a proposal for the Victoria meeting to create a corrigendum for the Fortran 90 standard. As part of this proposal, BSI suggested the following change with respect to an optional dummy argument being passed to optional argument of an intrinsic procedure: 179/38+. Add: (5) If it is an array, it must not be supplied as an actual argument to an elemental procedure unless an actual argument that is present is an array of the same rank. Discussion: It was intended that the rank of an expression should never vary. Note that this text again just focuses on the cases where rank causes a problem. I don't know the precise contents of WG5 paper N815A since I did not copy it to a local directory and it seems to no longer be available on the WG5 server (at least not through Richard's mirror), but presumably it is a refinement of N786A done at the Victoria meeting. X3J3 paper 92-156a added the example to the Discussion section (or repeated it from N815A) and this paper also has the minor edit following the addition of part (5) to the list. The minutes of meeting 122 show that the paper was approved by a vote of 20-3. - - - - - - - - >From a coworker here at SGI/CRI: The restriction should be that they can't use OPTIONAL arguments not present, not just OPTIONALS. In other words, it should be OK to have INDEX(a, b, back) with BACK optional, provided that BACK is present if the intrinsic is evaluated. ---------------------------------------------------------------------- NUMBER: 000008 TITLE: Optional arguments to MAX/MIN KEYWORDS: intrinsic function, MAX, MIN, optional, argument DEFECT TYPE: Interpretation STATUS: J3 consideration in progress BACKGROUND: Dick Hendrickson originally posed the question contained in this Interpretation Request. As will be seen in the Addendum, Richard Maine agrees with me that this question needs an official response. Hence, I am submitting on Dick's behalf (to steal a little more of his thunder). I have combined some of his and Richard's words. Any misstatements in transcription are most likely mine. This intro should be deleted later in the interp process. QUESTION: It appears that there is a missing "optional" in the description of the optional arguments [, A3, ...] in the MAX and MIN functions. In the Fortran 90 standard, the MAX/MIN descriptions said "optional arguments. A3, ...", but those words do not appear 13.14.64 of the Fortran 95 standard. Section 13.3 [217:27+] states ...optional arguments... are identified by the notation "optional" in the argument descriptions. and goes on to describe another notation for the arguments that are listed as optional. But it doesn't say anything about arguments given in [...] and NOT also listed as optional. Suggested change to the argument descriptions for MAX and MIN: Arguments. A1, A2 shall both have the same type which shall be integer or real and they shall both have the same kind type parameter. A3, ... (optional) shall have the same type and kind type parameter as A1. ANSWER: EDITS: SUBMITTED BY: Larry Rolison / Dick Hendrickson HISTORY: J3/97-245 m143 submitted - - - - - - - - Addendum: Dick's original question and the interchange that developed between he and Richard Maine: Date: Thu, 18 Sep 1997 13:02:28 -0500 To: x3j3@ncsa.uiuc.edu From: Dick Hendrickson Subject: (x3j3.1997-309) Is A3 optional for MAX or MIN functions My guess is that there is a missing "optional" in the description of [, A3, ...] in the MAX and MIN functions. In F90 the MAX/MIN descriptions said "optional arguments. A3,...", but I can't find those words in F95 13.14.64 Section 13.3 (217:27) says "...optional arguments... are identified by the notation "optional" in the arguments description." and goes on to describe another notation for the arguments that are listed as optional. But it say anything about arguments given in [...] and NOT also listed as optional. I don't know if we are doing bug fixes yet on F95, but shouldn't we change the argument description for MAX and MIN to Arguments. A1, A2 shall both have the same type which shall be integer or real and they shall all have the same type parameter. A3,... (optional) shall have the same type and type parameter as A1 It's clear what we meant to do, did I miss something simple somewhere? Dick - - - - - - - - Date: Thu, 18 Sep 1997 12:52:42 -0700 (PDT) From: Richard Maine To: Dick Hendrickson Cc: x3j3@ncsa.uiuc.edu Subject: (x3j3.1997-310) Is A3 optional for MAX or MIN functions Dick Hendrickson writes: > My guess is that there is a missing "optional" in the description of > [,A3,...] in the MAX and MIN functions. In F90 the MAX/MIN descriptions > said "optional arguments. A3,...", but I can't find those words > in F95 13.14.64 .... > It's clear what we meant to do, did I miss something simple somewhere? Its not quite so clear to me. You may have missed something subtle. Some intrinsics have multiple interfaces and there are subtle but critical differences between an argument that is optional as opposed to an argument that is omitted from one or more of the interfaces. What isn't clear is which of these categories MIN and MAX fit into. Is it one interface with an infinite number of optional arguments or is it an infinite number of interfaces, each with a different number of required arguments? MIN and MAX are rather "special" in any case in that it is impossible to write an interface for them (in a finite number of lines of code). I'm not entirely sure that they fit in either category. I'm not sure of the correct answer here - all I'm saying is that it isn't as simple a case as it sounds at first glance. You can actually change what is or isn't legal depending on exactly how you describe MIN and MAX (consider the restrictions in 12.4.1.5). It may be an error in f95, but I'd treat it as a "real" question, not as a typo. -- Richard Maine maine@altair.dfrc.nasa.gov - - - - - - - - Date: Thu, 18 Sep 1997 17:05:29 -0500 To: Richard Maine From: Dick Hendrickson Subject: (x3j3.1997-312) Re: Is A3 optional for MAX or MIN functions At 07:52 PM 9/18/97 +0000, Richard Maine wrote: >Dick Hendrickson writes: > > > My guess is that there is a missing "optional" in the description of > > [,A3,...] in the MAX and MIN functions. In F90 the MAX/MIN descriptions > > said "optional arguments. A3,...", but I can't find those words > > in F95 13.14.64 > .... > > It's clear what we meant to do, did I miss something simple somewhere? > >Its not quite so clear to me. You may have missed something subtle. >Some intrinsics have multiple interfaces and there are subtle but >critical differences between an argument that is optional as opposed >to an argument that is omitted from one or more of the interfaces. > >What isn't clear is which of these categories MIN and MAX fit into. >Is it one interface with an infinite number of optional arguments or >is it an infinite number of interfaces, each with a different number >of required arguments? It's also not clear to me, but, as I read the MAX/MIN description in Fortran 90 I'd say that A3,... are each optional arguments; not that the description is a shorthand for an infinite number of lists. If this is correct then upwards compatibility demands (well suggests anyhow) that A3, A4, ... are each optional and this leads to the surprising result that MAX(A1=1,A2=2, A4=4 ) is legal. > It may be an > error in f95, but I'd treat it as a "real" question, not as a typo. I guess I agree with that, unless someone has an obvious answer. Dick - - - - - - - - Date: Thu, 18 Sep 1997 15:38:57 -0700 (PDT) From: Richard Maine To: Dick Hendrickson Cc: x3j3@ncsa.uiuc.edu Subject: (x3j3.1997-313) Re: Is A3 optional for MAX or MIN functions Dick Hendrickson writes: > If this is correct then upwards compatibility demands (well > suggests anyhow) that A3, A4, ... are each optional and this leads > to the surprising result that MAX(A1=1,A2=2, A4=4 ) is legal. I think there might have been an interp related to that, but too many hot non-J3 things right now for me to take the time to search the interps. -- Richard Maine maine@altair.dfrc.nasa.gov [ Added note from Larry: This time I could not find the interp that Richard maybe remembers. At least nothing showed up when I searched both the A and B categories using A4 and MAX. ] ---------------------------------------------------------------------- NUMBER: 000009 TITLE: INTENT of MOLD argument to TRANSFER KEYWORDS: intrinsic function, TRANSFER, MOLD DEFECT TYPE: Interpretation STATUS: J3 consideration in progress BACKGROUND: Dick Hendrickson submitted the background and questions contained in this interpretation request. Since there was no "official" reply forthcoming, I've taken the liberty (with Dick's kind permission) of submitting his informal question as a formal interpretation request. I have adapted his original email message and the reply he got from Rich Maine to the basic interp request format so some of the words in this interp request are mine, not theirs. Any errors of interpretation of their words are mine. This background section can probably be deleted in a later phase of the interpretation processing. QUESTION: In 13.3 [page 218:2], Fortran 95 states: The nonpointer dummy arguments of the generic intrinsic procedures in 13.14 have INTENT(IN) if the intent is not stated explicitly. In general, an actual argument that corresponds to a dummy argument that does not have the INTENT(IN) attribute does not need to be defined; you need to look at the particulars of the invoked procedure to decide if an actual argument needs to be defined before the invocation. It is likely that the only intrinsic procedure argument affected by this change in wording is the MOLD argument to the TRANSFER function. The value of the MOLD argument is never needed so there is no reason to define it before invoking TRANSFER in a Fortran 90 program. But, apparently it needs to be defined in a Fortran 95 program. This could break a program that uses a local name in a subroutine as the MOLD argument and doesn't always define the name with a value, or didn't save it. In this case, MOLD is like the arguments to the numeric inquiry functions, the "attribute" is a compile time characteristic, not a run-time "value" and should have the same exception as for the inquiry functions. (1) Was general statement about INTENT(IN) quoted above intentionally added to the Fortran 95 standard (how did it get into the standard)? (2) Is it the intent of the standard to apply this general statement to the MOLD argument of the TRANSFER intrinsic function? ANSWER: (1) Yes. The cited text was became a part of the Fortran 95 standard as a result of applying the edits in Interpretation Request 184 to the Fortran 90 standard. The edits applied by Interpretation Request are included in Corrigendum 3. [ Thanks to Richard Maine for providing this clue. This comment should be removed in later processing. Just wanted to give credit where credit was due. ] (2) EDITS: SUBMITTED BY: Larry Rolison / Dick Hendrickson HISTORY: J3/97-246 m143 submitted ---------------------------------------------------------------------- NUMBER: 000010 TITLE: Meaning of embedded blanks in namelist input name KEYWORDS: NAMELIST, optional qualification, name, input DEFECT TYPE: Interpretation STATUS: J3 consideration in progress BACKGROUND: In running some older NAMELIST tests, a test case was encountered that has embedded blanks within the "optional qualification" following a namelist group object name: CHARACTER*10 string NAMELIST /junk/ string WRITE(9,*) ' $junk string( : ) = ''1234567890'' /' REWIND(9) READ(9,junk) IF (string .NE. '123457890') THEN PRINT *, 'string NE 1234567890, string = "', string, '"' PRINT *, 'String test FAILED' ELSE PRINT *, 'String test PASSED' END IF END While studying the standard to determine if the above program was standard- conforming or not, some questions arose about the use of "name" and embedded blanks in the namelist section 10.9.1.1. Among them were: Since a blank is a delimiter, should it be allowed to be embedded in a variety of places in a namelist input record that are not currently described by the standard? Do we want to strain namelist input scanning more than a reasonable amount? In normal Fortran terminology, the term "name" does not include subobject qualification. In section 2.5.1 Name and designator, lines 2 through 5, the standard states: A name is used to identify a program constituent, such as a program unit, named variable, named constant, dummy argument, or derived type. The rules governing the construction of names are given in 3.2.1. A subobject designator is a name followed by one or more of the following: component selectors, array section, array element selectors, and substring selectors. In section 10.9.1 Namelist Input, lines 13 to 16, the standard states: In each name-value subsequence, the name shall be the name of a namelist group list item with an optional qualification and the name with the optional qualification shall not be a zero-sized array, a zero-sized array section, or a zero-length character string. The optional qualification, if any, shall not contain a vector subscript. In section 10.9.1.1 Namelist group object names, lines 32 and 33, the standard states: The name in the input record may be preceded and followed by one or more optional blanks but shall not contain embedded blanks. QUESTION: (1) Does Section 2.5.1 mean that the optional qualification described in the 10.9.1 is not part of the name for namelist input? If the optional qualification is not part of the name, there seem to be no rules for where blanks and end-of-record may occur within the optional qualification. Also note that size of the name and the optional qualification together may be longer than the size of an input record if there are multiple levels of structure component qualification in a structure component reference. (2) Are embedded blanks allowed within substring and subscript qualifications in the namelist input? May an END-OF-RECORD occur in these same places? (3) More specifically, are embedded blanks/END-OF-RECORD allowed in the following places in namelist input? 1. Between the name and the left parenthesis of either a substring or subscript qualification? e.g., string (3:4) = '123' 2. Between tokens within the parenthesized qualifier? e.g., string( 3:4) = '123' e.g., string( 3:4 ) = '123' e.g., string( 3: 4 ) = '123' e.g., string( 3 : 4 ) = '123' e.g., string( : ) = '123' 3. Between the two sets of parentheses for array and substring notation? e.g., string ( : ) ( : ) = '123' 6. Within the two subscripts or start and end values themselves? e.g., string ( 2 0 : 3 0 ) = '123' (4) Are embedded blanks allowed within a reference to a structure? May an END-OF-RECORD occur within this reference? e.g., LONG__NAME % LEVEL1 ( 2 0 : 3 0 ) % string = '123' (5) Section 10.9.1.1, lines 32 and 33 currently state: The name in the input record may be preceded and followed by one or more optional blanks but shall not contain embedded blanks. Should the above lines have an addition along the following lines: Blanks shall not precede the left parenthesis of a substring or subscript qualification. Blanks may follow the left parenthesis or precede the right parenthesis of the substring or subscript qualification but shall not be embedded within the subscript or substring themselves. The end of record shall not occur within any part of the substring or subscript qualification. Blanks may occur between a subscript and a substring qualification. Note to committee: The above addition will then allow ( : ) and ( 2:3 ) but will not allow ( 1 0 : 2 0 ). Blanks will be allowed in between the subscript and substring reference: ( 1:2 ) ( 3:4 ). The following change is harder. If the derived type qualification is so long that it will not fit in one record, there are two choices that come to mind: * state that the input record must be long enough to contain the entire reference * allow the user to break up the structure reference to be able to specify it within an input record. The latter ability could be added to the standard via additional text along the following lines: Blanks shall not be embedded within the optional qualification provided for a structure reference. However, an end-of-record may occur after a percent (%) separator in an input record. The name may continue in the next record. This will allow a break at such places as: LONG__NAME%LEVEL1(20:30)%EOR string = '123' where EOR stands for end-of-record. EDITS: SUBMITTED BY: Joanne Brixius / Larry Rolison HISTORY: J3/97-253 m143 submitted ---------------------------------------------------------------------- NUMBER: 000011 TITLE: G editing typo KEYWORDS: G edit descriptor DEFECT TYPE: erratum STATUS: J3 consideration in progress In F95 section 10.5.4.1.2, the last line of the table shows an equivalent conversion of F(w-n).1,n('b'). This is different from the corresponding table in F90, which shows this conversion as F(w-n).0,n('b'). There is no obvious reason for this change; it appears to be a typo in f95. Should this conversion be F(w-n).0,n('b') as in Fortran 90? ANSWER: Yes, this was a typographical error in f95. EDIT: [171:23] Last line of the table in 10.5.4.1.2. Change ".1" to ".0" SUBMITTED BY: Richard Maine HISTORY: 97-225 m143 submitted Aug. 12, 1997 ---------------------------------------------------------------------- NUMBER: 000012 TITLE: Evaluation of Intrinsic Procedures KEYWORDS: Algorithm, Mathematical, Computational DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: 1. When the standard specifies an algorithm for computing a mathematical procedure, must a processor use the specified algorithm? Example: ANINT is defined as INT (A + 0.5). On some processors ANINT (16 000 001.0) evaluates to 16 000 002.0 using this algorithm. 2. May a processor return a mathematically equivalent result in the evaluation of a numeric intrinsic procedure? Example: If ANINT (16 000 001.0) can be computed as the more expected 16 000 001.0, may a processor do so? ANSWER: 1. No, a processor is not required to use the algorithm from the standard. 2. Yes, a processor may return the mathematically equivalent result in the evaluation of any numeric intrinsic procedure. DISCUSSION: The use of an algorithm in the definitions for intrinsic procedures is intended to describe the end result. It is not intended to require that a processor use a particular method of achieving that result. Thus, an algorithm specifies the mathematical results, not the computational results, of the evaluation of intrinsic procedures. This standard does not require a processor to use a particular accuracy or precision. Section 1.4, "Exclusions", states in part: "This standard does not specify: . . . (6) The physical properties of the representation of quantities and the method of rounding, approximating, or computing numeric values on a particular processor." [1:26, 1:37-38] EDITS: None. SUBMITTED BY: Keith H. Bierman HISTORY: 95-247r1 m134 Submitted as F90 interp 000202 with proposed response, approved 9-4, subsumes F90 interp 000200. 95-256 m134 Ballot failed, 10-6 95-260 m135 Proposed response, no action 96-023 m136 Proposed response, no action 96-054 m137 Proposed response, no action 96-117 m138 Proposed response, no action 97-259r1 m143 Re-submitted as F95 interp 000012 with proposed response 00-214 m153 Passed unanimously ---------------------------------------------------------------------- NUMBER: 000013 TITLE: Format of zero in list-directed and namelist output KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: 1. The fifth paragraph of Section 10.8.2 of the Fortran 90 standard clearly indicates that in list-directed output zero must be formatted according to exponential format. Most, though not all, of the implementations I tried use fixed format. Even the FCVS test suite assumes fixed format. Should exponential format be used for zero in list-directed output? 2. The same issue raised in question 1 applies to namelist output (see Section 10.9.2.1, paragraph 3). Should exponential format be used for zero in namelist output? ANSWER: HISTORY: 97-165 m143 Submitted ---------------------------------------------------------------------- NUMBER: 000014 TITLE: Format of complex numbers in list-directed and namelist output KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: 3. The seventh paragraph of Section 10.8.2 of the Fortran 90 standard states that complex numbers must be written with no embedded blanks unless the complex constant is broken across two records.. Some of the implementations I tested put a blank after the comma even when the entire constant fit in a single record. Is an implementation permitted to include a blank after the comma in a complex constant produced by list-directed output when the constant fits in a single record? 4. Is a blank permitted after the comma in a complex constant produced by namelist output when the constant fits in a single record? ANSWER: SUBMITTED BY: HISTORY: 97-165 m143 Submitted ---------------------------------------------------------------------- NUMBER: 000015 TITLE: Commas in list-directed output KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: 5. The first paragraph of Section 10.8.2 of the Fortran 90 standard states With the exception of adjacent nondelimited character constants, the values are separated by one or more blanks or by a comma optionally preceded by one or more blanks and optionally followed by one or more blanks. I have yet to find a Fortran implementation, other than my own, that satisfies this requirement. In particular, the statement PRINT *, 1, ',' 2 prints a comma immediately following the 1 on every implementation I tried. The comma was followed by zero, one, or two blanks in different implementations. Is a separator required between a constant other than a nondelimited character constant and a following nondelimited character constant in list-directed output? Is a separator required between a nondelimited character constant and a following constant that is not a nondelimited character constant? ANSWER: EDIT: SUBMITTED BY: HISTORY: 97-165 m143 Submitted ---------------------------------------------------------------------- NUMBER: 000016 TITLE: Character array constructors KEYWORDS: Character, array constructor, zero-size DEFECT TYPE: STATUS: duplicated by 000071 The f95 standard appears to leave the length of zero-sized character array constructors undefined. The penultimate paragraph of clause 4.5 says "The type and parameters of an array constructor are those of the expressions." If there are no elements, then the values of the type parameters might not be defined. The type and kind are always well defined at compile time. However, the length parameter for zero-sized character array constructors is not obviously well-defined, even at run-time. Zero-sized constructors are certainly allowed, as mentioned in the antipenultimate paragraph of clause 4.5: "An empty sequence forms a zero-sized rank-one array." Experimentation with different f90 compilers yields varying results. In the sample of question 2 below, one compiler gave a compile-time error message "array constructor has indeterminate character length". (Interestingly, it also gave that message when n=1, which should have been valid; some other variations gave compiler crashes). Another compiler gave the lengths as 2 and 5 and the n_calls as 1, obviously evaluating the presumed first element, even when the result had, in fact, no elements. QUESTION 1: Is the following a valid program and, if so, what len value does it print. program zero write (*,*) len( (/ ('abc', i = 1 , 0) /) ) end QUESTION 2: Is the following a valid program and, if so, what values does it print for the lengths and for n_calls. program zero_size integer :: n = 0 integer :: n_calls = 0 call sub('abc', n) write (*,*) 'n_calls = ', n_calls contains subroutine sub(string, n) character*(*) :: string integer :: n integer :: i write (*,*) len( (/ (string(:twice(i)), i = 1 , n) /) ) write (*,*) len( (/ (string(:twice(i)), i = 1 , n), 'abcde' /) ) end subroutine sub function twice(i) integer :: twice twice = 2*i n_calls = n_calls + 1 end function twice end program zero_size ANSWER: EDIT: SUBMITTED BY: Richard Maine HISTORY: 98-101 m143 submitted 20 Nov 1997 99-101 ? 99-207 ? m153 duplicated by interp 000071; processing 000016 complete ---------------------------------------------------------------------- NUMBER: 000017 TITLE: Characteristics of an array function result KEYWORDS: Characteristics, function DEFECT TYPE: Interpretatation STATUS: J3 consideration in progress Sections 12.2.1.1 and 12.2.2 of the Fortran 95 standard define rules for dummy arguments and function returns in the presence of explicit interfaces that allow array bounds expressions to be evaluated on either the calling side or the called side of a call. The interpretation provided for RFI 000049 on the X3J3 website clarifies and reinforces the conditions that permit evaluation on either side of the call. The erratum published in the same file for RFI 000070 changes the semantics of dummy arguments. The erratum does not explicitly mention function results, but it might be considered to imply a similar change to the semantics of function results. The erratum provided for RFI 000070 refers to altered text for the interpretation provided for RFI 000049. The version of the interpretation that appears in the file on the X3J3 website does not contain the altered text. The definition of characteristics of function results as stated in Section 12.2.2 of the Fortran 95 standard permits more efficient implementation of array-valued functions, at least for some architectures, than the definition implied by the erratum provided for RFI 000070. For Sun, it is more efficient for the calling routines to allocate space for array results than to have the called routines allocate the space. In order for the calling routine to allocate space for an array result, it must know the size of the array. To determine the size of the array, it must evaluate the array bounds expressions given in the explicit interface for the function. Section 12.2.2 of the Fortran 95 standard requires the values of the nonconstant bounds expressions given in an explicit interface to be the same as the values of the bounds expressions given in the corresponding function definition. Thus, the values of the nonconstant bounds expressions used to determine the size of the array result can be passed to the called routine, avoiding any need for the called routine to re-evaluate those expressions. Because Fortran 95 allows user-defined routines to appear in bounds expressions, evaluating the bounds expressions more than once per call could prove inefficient and confusing. The change implied by the erratum provided for RFI 000070 would remove the nonconstant bounds expressions from the characteristics of function results. The shape would still be a characteristic, but the same shape can be produced by many different values of the bounds expressions. Thus, the values of the nonconstant bounds expressions used in the called routine may differ from the values of the corresponding expressions in the explicit interface. For example, consider the explicit interface INTERFACE FUNCTION FOO(F, G, H) INTERFACE PURE INTEGER FUNCTION F() END FUNCTION PURE INTEGER FUNCTION G() END FUNCTION PURE INTEGER FUNCTION H() END FUNCTION END INTERFACE CHARACTER*(F()) FOO(G():H()) END FUNCTION END INTERFACE The definition given in Section 12.2.2 of the Fortran 95 standard requires the values of the length and bounds expressions in the interface to be the same as the values of the corresponding length and bounds expressions in the function definition. Under the definition implied by the erratum provided for RFI 000070, the shapes must match, but the values of the nonconstant bounds expressions need not. Thus, the function definition might be FUNCTION FOO(F, G, H) INTERFACE PURE INTEGER FUNCTION F() END FUNCTION PURE INTEGER FUNCTION G() END FUNCTION PURE INTEGER FUNCTION H() END FUNCTION END INTERFACE CHARACTER*(F()) FOO(G()-1:H()-1) . . . END FUNCTION In this case, the values of the bounds expressions used in the called routine must be the values of the expressions specified in the function definition, not the values of the expressions specified in the interface block. QUESTION: If a bound of a function result array is not a constant expression, is the exact dependence on the entities in the expression a characteristic of the function result? ANSWER: EDITS: REFERENCES: 95-006a, F90/000027, F90/000049 & F90/000070 SUBMITTED BY: Robert Paul Corbett HISTORY: J3/98-114 submitted ---------------------------------------------------------------------- NUMBER: 000018 TITLE: ELEMENTAL procedures with no arguments KEYWORDS: Elemental, procedure DEFECT TYPE: STATUS: J3 consideration in progress Section 12.7.2 of IS 1539-1:1997 seems to assume there is at least one argument to an elemental procedure. The semantics of the following examples do not seem to be clearly specified. Example 1: ELEMENTAL INTEGER FUNCTION f() f = 0 END Example 2: ELEMENTAL INTEGER FUNCTION g(i,j) INTEGER,INTENT(IN) :: i,j g = i + j END Example 3: ELEMENTAL INTEGER FUNCTION h2(i) INTEGER,INTENT(IN),OPTIONAL :: i h = i END Example 4: ELEMENTAL SUBROUTINE s() REAL x,y,z x = 0 y = 0 z = x/y END QUESTION 1: What is the shape of a reference to function F in example 1? Is it scalar? QUESTION 2: If G() is referenced as G(iscalar,jarray(1:0)), the result is a zero-sized array. Is "iscalar" referenced (need it be defined)? Is the body of G() executed? QUESTION 3: What is the shape of a reference to H2() if the argument is textually not present? QUESTION 4: When subroutine S is invoked, how many times is it executed? Is this example standard-conforming, or may a processor raise a divide-by-zero exception? ANSWER: (1) Yes, A reference to F() is scalar. Section 12.7.2 [214:28-29] says that "If the actual arguments are all scalar, the result is scalar." (2) It is not possible to tell, in Fortran 95, whether the body of G() is executed, so that part of the question has no answer. [no edit required] Yes, ISCALAR must be defined; this is the same situation as writing ISCALAR + JARRAY(1:0) directly, with no user-defined ELEMENTAL procedure being used. [no edit required] (3) If the I argument to H2 is textually absent, a reference to H2 returns a scalar result (cf. answer to question 1). Note that execution of this procedure is not standard-conforming if the optional argument is not present. The "H = I" line should be replaced by IF (PRESENT(I)) THEN H = I ELSE H = 0 ! or some other desired scalar value END IF [no edit required] (4) The subroutine is executed once per invocation. This is because any reference to the subroutine has no array arguments and so is not an "elemental reference" (section 12.4.3 [7-10]) but a normal subroutine reference. The example is not standard-conforming on a processor that does not allow division by zero. [no edit required] EDITS: None. SUBMITTED BY: Malcolm Cohen HISTORY: 98-117 m144 Submitted 00-123 m152 Revised by submitter (version above) but withdrawn for further study without vote. ---------------------------------------------------------------------- NUMBER: 000019 TITLE: Result of NULL intrinsic associated with CHARACTER(*) dummy argument KEYWORDS: NULL intrinsic, assumed character length parameter, argument association, pointer association DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Consider the following program. PROGRAM P CALL SUB(NULL()) CONTAINS SUBROUTINE SUB(C) CHARACTER(*), POINTER :: C PRINT *, LEN(C) END SUBROUTINE SUB END PROGRAM P According to 7.1.4.1 [91:27-30], "The data type, type parameters and rank of the result of the intrinsic function NULL when it appears without an argument are determined by the pointer that becomes associated with the result. See Table 7.2." In this case, the pointer that becomes associated with the result is the corresponding dummy argument when the result appears as an actual argument. However, according to 5.1.1.5 [51:14-18], a dummy argument of type character, with a character length parameter of *, "assumes the length of the associated actual argument when the procedure is invoked." Is this a standard conforming program? If so, how is the length of C determined, and what should be the output of this program? ANSWER: EDIT: SUBMITTED BY: Henry Zongaro HISTORY: 98-148 m145 Submitted ---------------------------------------------------------------------- NUMBER: 000020 TITLE: Execution of a WHERE statement within a WHERE construct KEYWORDS: WHERE statement, WHERE construct DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: 7.5.3.2 [113:17-19] indicates that: Upon execution of a WHERE statement or a WHERE construct statement that is part of a , the pending control mask is established to have the value m .AND.(.NOT. mask-expr). c [112:41-45] indicates that: Upon execution of an ENDWHERE statement, the control mask and pending control mask are established to have the values they had prior to the execution of the corresponding WHERE construct statement. Following the execution of a WHERE statement that appears as a , the control mask is established to have the value it had prior to the execution of the WHERE statement. Notice that after execution of an ENDWHERE statement, the pending control mask is established to have the value it had prior to the execution of the corresponding WHERE construct statement, but the same is not the case for the pending control mask established by the execution of a WHERE statement that appears as a . According to this, the output of the following program PROGRAM P INTEGER :: A(2) = 0, B(2) = 0 WHERE((/.TRUE.,.TRUE./)) WHERE((/.TRUE.,.FALSE./)) A = 1 ELSEWHERE A = 2 END WHERE PRINT *, A WHERE((/.TRUE.,.TRUE./)) WHERE((/.TRUE.,.FALSE./)) B = 1 END WHERE ELSEWHERE B = 2 END WHERE PRINT *, B END PROGRAM P will be 1 2 1 0 Was this difference in behaviour intended by the committee? ANSWER: EDIT: SUBMITTED BY: Henry Zongaro HISTORY: 98-149 m145 Submitted ---------------------------------------------------------------------- NUMBER: 000021 TITLE: Restrictions on on END INTERFACE KEYWORDS: INTERFACE block, END INTERFACE, generic procedures DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: According to section 12.3.2.1 [194:18-20] The may be included in the only if it was provided in the and, if included, shall be identical to the in the . It is not clear what the words "shall be identical" were intended to mean. In particular, were they intended to merely convey the idea that the two s shall specify the same entity, even though such an entity might be represented in more than one way, or were they intended to convey something more restrictive? Are either of the following examples standard conforming programs? Example 1: PROGRAM P INTERFACE OPERATOR(.NE.) LOGICAL FUNCTION F(I, C) INTEGER, INTENT(IN) :: I CHARACTER(*), INTENT(IN) :: C END FUNCTION F END INTERFACE OPERATOR(/=) END PROGRAM P Example 2: MODULE MOD INTERFACE GEN SUBROUTINE SUB1(I) INTEGER :: I END SUBROUTINE SUB1 END INTERFACE END MODULE MOD PROGRAM P USE MOD, G1=>GEN, G2=>GEN INTERFACE G1 SUBROUTINE SUB2(L) LOGICAL :: L END SUBROUTINE SUB2 END INTERFACE G2 END PROGRAM P ANSWER: EDIT: SUBMITTED BY: Henry Zongaro HISTORY: 98-150 m145 Submitted ---------------------------------------------------------------------- NUMBER: 000022 TITLE: Use of NULL() as initialization KEYWORDS: NULL intrinsic, initialization, default initialization, DATA statement DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Rules R429, R505 and R540 respectively describe the syntax for default initialization of pointer components, pointer objects in type declaration statements and pointer objects in DATA statements. These rules seem to indicate that NULL is to be considered a keyword in those contexts. This has the surprising effect that the first example below is a standard conforming program, while the second is not. That is, in some contexts, something that looks very much like a reference to an intrinsic function, is in fact a keyword followed by parentheses. Example 1: MODULE MOD INTRINSIC NULL END MODULE MOD PROGRAM PROG USE MOD, DISASSOCIATE=>NULL INTEGER, PARAMETER :: NULL = 17 INTEGER :: J = NULL INTEGER :: I INTEGER, POINTER :: P => NULL(), P2 DATA P2, I/NULL(), NULL/ TYPE DT INTEGER, POINTER :: P => NULL() END TYPE DT TYPE DT2 INTEGER, POINTER :: I INTEGER :: J END TYPE DT2 TYPE(DT2) :: S = DT2(DISSASSOCIATE(), NULL), S2 DATA S2/DT2(DISSASSOCIATE(), NULL)/ END PROGRAM PROG Example 2: MODULE MOD INTRINSIC NULL END MODULE MOD PROGRAM PROG USE MOD, DISASSOCIATE=>NULL INTEGER, POINTER :: P => DISASSOCIATE(), P2 DATA P2/DISASSOCIATE()/ TYPE DT INTEGER, POINTER :: P => DISASSOCIATE() END TYPE DT END PROGRAM PROG In some places in the scoping unit of PROG example 1, NULL() is used to specify initialization or default initialization, while in others NULL is a named constant, and DISSASSOCIATE() must be used to specify initialization. 1) Is example 1 a standard conforming program? 2) Is example 2 a standard conforming program? 3) Was it the intent of the committee that, within the contexts of R429, R505 and R540, NULL should be treated strictly as a keyword rather than as a reference to an intrinsic function? ANSWER: EDIT: SUBMITTED BY: Henry Zongaro HISTORY: 98-151 m145 Submitted ---------------------------------------------------------------------- NUMBER: 000023 TITLE: Termination of the previous record by a WRITE statement KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Suppose a sequential formatted file is positioned within a record as a result of a nonadvancing READ. 1. If the next operation performed on the file is a WRITE, can the current record be terminated at its current position before the next record is written? Section 9.2.1.3.2 appears to preclude the record from being terminated, but at least one Fortran 90 implementation does the record in such an instance. 2. If next operation is a nonadvancing WRITE and the number of characters written does not extend to the end of the current record, are the remaining characters at the end of the record preserved? ANSWER: EDIT: SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 1) ---------------------------------------------------------------------- NUMBER: 000024 TITLE: Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Suppose a partial record has been written as a result of a nonadvancing WRITE. If the file is closed, or a BACKSPACE, ENDFILE, or REWIND statement is performed on the file, must the partial record be terminated? ANSWER: DISCUSSION: EDIT: SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 2) ---------------------------------------------------------------------- NUMBER: 000025 TITLE: List-directed input: types of variables corresponding to repeated values KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: When a repeat count is used in list-directed input, must all the variables into which the repeated value is read have the same type? I see no reason in the standard to assume that restriction, but at least one Fortran 90 implementation assumes it ANSWER: DISCUSSION: EDIT: SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 3) ---------------------------------------------------------------------- NUMBER: 000026 TITLE: List-directed input: types of variables corresponding to repeated values KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Consider the example CHARACTER*80 STRING COMPLEX Z READ (*, *) Z, STRING Support the input consists of 2*(1.0, 0.0) After the READ, should Z contain (1.0,0.0) and should STRING contain '(1.0,'? ANSWER: DISCUSSION: EDIT: SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 4) ---------------------------------------------------------------------- NUMBER: 000027 TITLE: Sequential formatted I/O: position of the left tab KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: When a file is positioned within a record at the start of sequential formatted I/O, where is the left tab limit (see Section 10.6.1.1)? Is it at the start of the record or at the point where the file was positioned at the start of execution of the statement? ANSWER: DISCUSSION: EDIT: SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 5) ---------------------------------------------------------------------- NUMBER: 000028 TITLE: Implicitly Typed Statement Function Character Dummy KEYWORDS: statement function, constant expression, implicit typing DEFECT TYPE: Clarification STATUS: J3 consideration in progress QUESTION: Is the following program-unit standard-conforming? SUBROUTINE sub(n) IMPLICIT CHARACTER*(n) (c) stmtfn(ch) = LEN(ch) END A quick survey of 6 compilers showed no consensus on whether this was legal, with 3 accepting it (as standard-conforming), 2 rejecting it, and 1 crashing with an internal error. ANSWER: No. DISCUSSION: [51:32-33] requires explicitly-specified character lengths for statement functions and statement function dummy arguments to be constant specification expressions. This requirement should also be applied to implicitly typed entities. EDIT: [211:35+] Add new paragraph "If a statement function or statement function dummy argument is implicitly typed and is of type character, its corresponding character length specification (if any) shall be a constant specification expression." SUBMITTED BY: Malcolm Cohen HISTORY: 98-164 Submitted ---------------------------------------------------------------------- NUMBER: 000029 TITLE: Association of a pointer actual argument with a dummy argument KEYWORDS: derived type, assignment DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: According to Fortran 90, intrinsic assignment of derived type entities does not invoke defined assignment for components of these entities, even if it exists. Should this situation have been corrected in Fortran 95 to avoid breaking encapsulation of derived types? That is, in the example program below, is the final assignment statement intended to invoke the user-defined assignment routine for the "name" components of "a" and "b", or should it do pointer assignment on the (PRIVATE) "value" components of the "name" components? MODULE lib_varying_string TYPE varying_string PRIVATE CHARACTER,POINTER :: value(:) END TYPE INTERFACE ASSIGNMENT(=) MODULE PROCEDURE assign_vs_to_vs END INTERFACE CONTAINS SUBROUTINE assign_vs_to_vs(var,expr) TYPE(varying_string),INTENT(OUT) :: var TYPE(varying_string),INTENT(IN) :: expr ALLOCATE(var%value(SIZE(expr%value,1))) var%value = expr%value END SUBROUTINE END PROGRAM programme USE lib_varying_string TYPE mytype TYPE(varying_string) name END TYPE TYPE(varying_string) x,y TYPE(mytype) a,b x = y ! invokes "assign_vs_to_vs(x,(y))". a%name = b%name ! invokes "assign_vs_to_vs(a%name,(b%name))" a = b ! in F90, pointer assigns the "value" components END ANSWER: Yes, Fortran 95 should have corrected this mistake in Fortran 90. The final assignment above should invoke "assign_vs_to_vs(a%name, (b%name))". REFERENCES: ISO/IEC 1539:1997 (E) sections 7.5.1.2 and 7.5.1.5. EDITS: 1. Add a new item to the numbered list at the end of section 1.5.1 [3:32+] "(3) Intrinsic assignment for derived types now invokes defined assignment on nonpointer components for which the intrinsic assignment has been overridden by an interface block with an ASSIGNMENT(=) specifier." 2. Replace "and intrinsic assignment for nonpointer components." in section 7.5.1.5 [109:37] with ", defined assignment for nonpointer components of derived type for which there is an accessible interface block with an ASSIGNMENT(=) specifier for objects of that type, and intrinsic assignment for other nonpointer components." 3. In note 7.44, change "using the derived-type intrinsic assignment statement" [110:4-5] to "using defined assignment if there is an accessible interface block with an ASSIGNMENT(=) specifier overriding the intrinsic assignment for objects of that type, and using the derived-type intrinsic assignment statement otherwise." Note: This is MTE work item M16 for Fortran 2000. The corresponding edits to F2K have not been made as of 00-007r1. SUBMITTED BY: Malcolm Cohen HISTORY: 97-197 m142 Submitted 97-197 m145 Passed unanimously as amended {see 98-167 minutes} ---------------------------------------------------------------------- NUMBER: 000030 TITLE: Ordering requirements on definition of specification functions KEYWORDS: Specification expressions, specification functions DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Consider the following program unit. MODULE MOD INTERFACE INT MODULE PROCEDURE F1, F2 END INTERFACE CONTAINS INTEGER PURE FUNCTION F1(I) INTEGER :: A(INT(1_4)), B(INT(1_2)) ! A(1), B(19) INTEGER, PARAMETER :: KIND = SIZE(A) ! KIND == 1 INTEGER(KIND), INTENT(IN) :: I F1 = 17 END FUNCTION F1 INTEGER PURE FUNCTION F2(J) INTEGER :: C(INT(2_4)) ! C(2) INTEGER, PARAMETER :: KIND = SIZE(C) ! KIND == 2 INTEGER(KIND), INTENT(IN) :: J F2 = 19 END FUNCTION F2 END MODULE MOD In processing the references to "INT(1_4)" and "INT(1_2)" in F1, the processor needs to determine whether the references are to the intrinsic function, INT, or to one of the specific procedures, F1 or F2. Determining that requires the processor to have determined the kind type parameter of the dummy argument J, of F2. In turn, that requires the processor to determine whether the reference to "INT(2_4)" is a reference to the intrinsic function, INT, or to one of the specific procedures, F1 or F2. Determining that requires the processor to determine the kind type parameter of the dummy argument I, which requires it to determine that "INT(1_4)" in F1 was a reference to the intrinsic function INT. After all this is determined, the processor can determine that the reference to "INT(1_2)" in the declaration of B in F1 is a reference to the specification function F2. According to 7.1.6.1 [94:38-41], "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the inquiry function in the same statement." According to 7.1.6.2 [96:27-37], "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. If a specification expression includes a reference to an inquiry function for a type parameter or an array bound of an entity specified in the same , the type parameter or array bound shall be specified in a prior specification of the . The prior specification may be to the left of the inquiry function reference in the same statement. If a specification expression includes a reference to the value of an element of an array specified in the same , the array shall be completely specified in prior declarations." The rules regarding references to variables in a specification expressions and initialization expressions require a strict left-to-right, top-to-bottom ordering between specification and inquiry. Specification functions appear to be unrestricted in this respect. Assuming that the processor supports integers with kind type parameters of 1, 2 and 4, was it the intent of the committee that the program unit above should be standard-conforming? ANSWER: EDIT: SUBMITTED BY: Henry Zongaro HISTORY: 98-176 m146 Submitted ---------------------------------------------------------------------- NUMBER: 000031 TITLE: Association of pointer function result with INTENT(OUT) dummy argument KEYWORDS: Pointer association, dummy argument association, intent attribute DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Consider the following program. PROGRAM P INTEGER, TARGET :: T CALL SUB(FPTR()) CONTAINS FUNCTION FPTR() INTEGER, POINTER :: FPTR FPTR => T END FUNCTION FPTR SUBROUTINE SUB(IO) INTEGER, INTENT(OUT) :: IO IO = 17 END SUBROUTINE SUB END PROGRAM P According to 12.4.1 [200:30-32], "If a dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be currently associated with a target and the dummy argument becomes argument associated with that target." According to 12.4.1 [201:19-21], "If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable." According to 5.1.2.3 [53:29-31], "The INTENT(OUT) attribute specifies that. . . any actual argument that becomes associated with such a dummy argument shall be definable." The definition of "definable" supplied in Annex A (the term does not appear to be defined in normative text) is: "A variable is <> if its value may be changed by the appearance of its or on the left of an ." According to this definition, "definable" is a property of variables only. In the example above, the actual argument is not a variable. However, the actual argument is pointer associated with an object that is definable. The text cited from 5.1.2.3 refers to the "actual argument that becomes associated with the dummy argument", but the first piece of text cited from 12.4.1 makes it clear that when the actual argument is a pointer, it is the target with which it is associated that becomes argument associated with the dummy argument, and not the actual argument itself. Was it the intent of the committee that this program should not be standard-conforming? ANSWER: EDIT: SUBMITTED BY: Henry Zongaro HISTORY: 98-177 m146 Submitted ---------------------------------------------------------------------- NUMBER: 000032 TITLE: Is the TRANSFER function result undefined? KEYWORDS: transfer function, undefined, processor dependent DEFECT TYPE: STATUS: J3 consideration in progress The result value section of the TRANSFER function says "...If the physical representation of the result is longer than that of SOURCE, the physical representation of the leading part is that of SOURCE and the remainder is undefined." ^^^^^^^^^^^^^^^^^^^^^^^^^^ and case (ii) gives an example of a transfer of 3 reals to 2 complexes with the imaginary part of the second complex being undefined. Where can you use this form of TRANSFER. There's a general prohibition about referencing undefined things. Doesn't that apply to expressions containing TRANSFER as well? Something like X = transfer (four_bytes,eight_bytes) or X = transfer(transfer(four_bytes,eight_bytes), four_bytes) reference the undefined part. Maybe in the latter case we could say that the "reference" in the outer transfer doesn't "require the value" of all of its argument. But that seems like an odd reading to me. We can't use it for functions like SIZE, because they only allow their argument to be undefined if it is a single variable name (13.8.5). The only thing I can think of is passing to a procedure argument that has no INTENT specified but that uses the defined part of the argument as if it were INTENT(IN). The intent can't be specified because INTENT(IN) arguments must be defined on entry. Question: Should the phrase be changed from "the remainder is undefined" to "the remainder is processor dependent"? ANSWER: EDIT: SUBMITTED BY: Dick Hendrickson HISTORY: Submitted 7/25/98 The following is a reply from Malcolm to an informal question ----------- From: malcolm@nag.co.uk (Malcolm Cohen) Errors-To: x3j3-request@zonker.ncsa.uiuc.edu X-Sequence: x3j3@ncsa.uiuc.edu 1998-205 Subject: (x3j3.1998-205) Re: informal question about the TRANSFER function To: x3j3@ncsa.uiuc.edu Date: Fri, 3 Jul 1998 16:46:21 +0000 (BST) Hi Dick, You might want to make this an interp request, but here is my opinion anyway. > The result value section of the TRANSFER function says > > "...If the physical representation of the result is longer than that > of SOURCE, the physical representation of the leading part is that of SOURCE > and the remainder is undefined." > ^^^^^^^^^^^^^^^^^^^^^^^^^^ I think this should say "processor dependent" or the usual other weasel words when we mean any value can result but it is legal. I.e. I don't think the word "undefined" was intended in its "definition status" interpretation. And if it was so intended, it is broken because a function reference *cannot* have an "undefined" definition status - the concept is only applicable to variables, see below. > and case (ii) gives an example of a transfer of 3 reals to 2 complexes > with the imaginary part of the second complex being undefined. > > Where can you use this form of TRANSFER. There's a general prohibition > about referencing undefined things. Doesn't that apply to expressions > containing TRANSFER as well? Something like This is a bit difficult. According to 2.5.4, definition status is something that variables have; it is not a property of an expression value. This is made more confusing by: "Any variable or function reference used as an operand shall be defined at the time the reference is executed." [97:1] The mention of function reference is confusing, because a function is not allowed to return without fully defining its result, viz "If the result variable is not a pointer, its value shall be defined by the function." [207:28] All in all, I would say that the standard is confusing/misleading viz: (1) "undefined" is being used to mean "not defined by this standard"; we should change it to "processor determined" to clarify this. (2) "or function reference" in [97:1] is spurious and should be deleted. However, I would take the definition of "definition status" in 2.5.4 as being definitive in disallowing the concept of "undefined [definition status]" function references. Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk) SUBMITTED BY: Dick Hendrickson HISTORY: 98-183 Submitted ---------------------------------------------------------------------- NUMBER: 000066 TITLE: Errors in processing data transfer statements KEYWORDS: ERR=; IOSTAT=; Data transfer statements DEFECT TYPE: Erratum STATUS: Passed by J3 meeting Consider the following program. INTEGER :: A(10), IDX, J OPEN(10, FORM='UNFORMATTED', ACCESS='SEQUENTIAL', STATUS='OLD', & ACTION='READ') READ(10, IOSTAT=IOS) IDX, J, A(IDX) END If an error occurs while processing the variable J in the data transfer statement, does this program become non-standard conforming? According to 9.4.3: "If an error condition or an end-of-file condition occurs during execution of an input/output statement, execution of the input/output statement terminates and if the input/output statement contains any implied-DOs, all of the implied-DO variables in the statement become undefined. If an error condition occurs during execution of an input/output statement, the position of the file becomes indeterminate. If an error or end-of-file condition occurs on input, all input list items become undefined." According to 9.4.4: "The effect of executing a data transfer input/output statement shall be as if the following operations were performed in the order specified: (1) Determine the direction of data transfer (2) Identify the unit (3) Establish the format if one is specified (4) Position the file prior to data transfer (9.2.1.3.2) (5) Transfer data between the file and the entities specified by the input/output list (if any) or namelist (6) Determine whether an error condition, an end-of-file condition, or an end-of-record condition has occurred (7) Position the file after data transfer (9.2.1.3.3) (8) Cause any variables specified in the IOSTAT= and SIZE= specifiers to become defined." A simple reading of this seems to indicate that the point at which the error occurs and is detected by a standard-conforming processor is unspecified. Because IDX becomes undefined, the reference to IDX in the variable A(IDX) is incorrect. However, this is a very common style of coding I/O operations in Fortran. QUESTION 1: Was it the committee's intent that such a program should not be standard-conforming in the presence of an error condition? QUESTION 2: Does the fact that the error occurred before the item A(IDX) was processed mean that there was no reference to IDX, and hence, that the program is standard-conforming? ANSWER 1: No. ANSWER 2: Yes. DISCUSSION: The referenced paragraph (9.4.4) is misleading. The entire I/O list is not necessarily expected to be processed in the presence of an error. EDIT: Section 9.4.4, list item 6 [150:33], delete "an error condition,", and change ", or" to "or" Section 9.4.4, add the following after list item (8): "If an error condition occurs during any of the above operations, execution of the data transfer statement terminates, any variable specified in an IOSTAT= specifier becomes defined, and the error condition is processed as described in 9.4.3." SUBMITTED BY: Henry Zongaro HISTORY: 99-177 m150 submitted 99-212 m150 approved uc 00-May failed J3 letter ballot 00-213 m153 passed unanimously ---------------------------------------------------------------------- NUMBER: 000067 TITLE: Writing zeros KEYWORDS: list-directed output, namelist output DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot The standard currently requires a real zero to be written in exponential form when using list-directed or namelist output. QUESTION: Is this requirement intentional or an oversight? ANSWER: The requirement is an oversight. DISCUSSION: The G edit descriptor was changed in Fortran 90 to format a real zero as if an F edit descriptor were provided in most cases. The same change was not made for list-directed or namelist output, but should have. REFERENCES: ISO/IEC 1539-1:1997(E), Sections 10.5.4.1.2, 10.8.2, and 10.9.2.1 EDITS: [3:32+] In section 1.5.1, add the following as list item (3): (3) List directed and namelist output statements produce a real constant zero for a real value that is zero, and for the real or imaginary part of a complex value that is zero. In Fortran 95, these real constants are produced with the effect of an F edit descriptor, instead of an E edit descriptor. [4:24+] In section 1.5.2, add the following as list item (7): (7) List directed and namelist output statements produce a real constant zero for a real value that is zero, and for the real or imaginary part of a complex value that is zero. In Fortran 95, these real constants are produced with the effect of an F edit descriptor, instead of an E edit descriptor. [177:41] In section 10.8.2 (List-directed output), fifth paragraph, change "If the magnitude x is within this range" to "If the magnitude x is within this range or is zero" [182:33] In section 10.9.2.1 (Namelist output editing), third paragraph, change "If the magnitude x is within this range" to "If the magnitude x is within this range or is zero" SUBMITTED BY: Robert Corbett HISTORY: 99-193 m150 Submitted 99-213r1 m150 approved uc 00-210 m153 Passed by letter ballot ---------------------------------------------------------------------- NUMBER: 000068 TITLE: Asterisks as I/O units KEYWORDS: Asterisk, I/O, unit DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot Question: 1. Does the Fortran 95 standard require the external unit corresponding to the I/O unit identified by an asterisk for input or output to be the same as the external unit identified by some fixed nonnegative integer value? 2. Can the I/O unit identified by an asterisk for input or output correspond to more than one external unit? 3. If the external unit identified by an integer value that corresponds to the I/O unit identified by an asterisk for input or output is closed, does that cause the I/O unit identified by an asterisk to become disconnected? Answer: 1. No. 2. No. 3. Yes. Discussion: The submitter states: At least one Fortran 95 implementation uses -1 as the value of the I/O unit identified by an asterisk. A carefully constructed INQUIRE statement can expose this value to the user. Many users expect I/O to the units identified by asterisks to continue to work even after the corresponding units identified by integer values have been closed. 1. There is no requirement in the standard that the asterisk correspond to an external-file-unit. 2. For the units identified by the asterisk, the text of section 9.3.2 does not allow two or more units to be connected simultaneously to the same external device or file [139:8-9]. An edit is supplied to clarify this situation. 3. There might not be an external-file-unit that corresponds to the io-unit specified by an asterisk, as clarified by the edit below. If there is, it is permissible to execute a CLOSE statement on them as on any other unit. REFERENCES: ISO/IEC 1539-1:1997(E), Sections 9.3 and 9.4.4.2 EDITS: Add the following text to the end of the last paragraph before section 9.3.1 [138:34+]: "An asterisk used in an input statement may identify the same as a particular . An asterisk used in an output statement may identify the same as another particular ." SUBMITTED BY: Robert Corbett HISTORY: 99-192 m150 Submitted 99-215r1 m150 approved uc 00-208 m153 passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000069 TITLE: What is a numeric character? KEYWORDS: list-directed input DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot Section 10.8.1 of the Fortran 95 standard states If the next effective item is of type default character and ... (4) The leading characters are not numeric followed by an asterisk, ... The standard does not define what a numeric character is. QUESTION: What is a numeric character? ANSWER: A numeric character is a . REFERENCES: ISO/IEC 1539-1:1997(E), Section 10.8.1 EDITS: Section 10.8.1, list item (4), [176:17], replace the text (4) The leading characters are not numeric followed by an asterisk with (4) The leading characters are not s followed by an asterisk SUBMITTED BY: Robert Corbett HISTORY: 99-191 m150 Submitted by Robert Corbett 99-214 m150 J3 draft response, approved uc 00-209 m153 passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000070 TITLE: Asymmetry between constant specification and initialization expressions KEYWORDS: Initialization expressions; specification expressions DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following programs. PROGRAM P1 REAL :: B = 4.0*ATAN(1.0) PRINT *, B END PROGRAM P1 PROGRAM P2 INTEGER :: A(INT(4*ATAN(1.0))) = 17 PRINT *, A END PROGRAM P2 According to 7.1.6.1 program unit P1 is not standard-conforming because of the reference to the intrinsic function ATAN which is not permitted in an initialization expression. According to 7.1.6.2 program unit P2 is standard-conforming; the reference to the intrinsic function ATAN is allowed by item (8) in the definition of a restricted expression. Expressions in the array bounds of an initialized entity are only required to be constant specification expressions, not initialization expressions. Was it the committee's intent to permit ATAN to appear in the array bounds of an initialized entity but not in the initialization value? ANSWER: No, this was not the intent. These expressions should have been described as initialization expressions instead of as constant expressions. This error also occurs for the definitions of an automatic entity, common block definitions and component definitions. The edits below change all of these to require initialization expressions instead of constant expressions. EDIT: [39:15] Change "a constant specification" to "an initialization". {Fix array components.} [39:23] Change "a constant specification" to "an initialization". {Fix character string components.} [40:30] Change "a constant" to "an initialization". {Fix note.} [48:47-48] Change "may be a nonconstant expression provided the specification expression" to "shall be an initialization expression unless it". [49:1-3] Delete "If a ... nonconstant expression." [49:4-5] Change "such a nonconstant expression" to "a that is not an initialization expression". {Fix definition of "automatic object".} [49:9] Change "a nonconstant expression" to "an expression that is not an initialization expression". {Fix evaluation time for character length.} [51:33] Change "a constant specification" to "an initialization". {Fix statement function character lengths.} [54:33] Change "nonconstant specification" to "not initialization". {Fix automatic array definition.} [54:34] Change "nonconstant specification" to "not initialization". {Fix evaluation time for explicit-shape array bounds.} [54:36] Change "the specification" to "any bounds". [56:32] Change "nonconstant specification" to "not initialization". {Fix evaluation time for assumed-size array bounds.} [56:34] Change "the specification" to "any bounds". [69:3-4] Change "a constant specification expression (7.1.6.2)" to "an initialization expression (7.1.6.1)". {Fix common block array-specs.} [192:26] Change "a constant" to "an initialization". {Fix characteristics of function results.} SUBMITTED BY: Henry Zongaro HISTORY: 99-178 m150 submitted 99-216r1 m150 approved uc 00-133 m152 additional edit, approved uc 00-208 m153 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000071 TITLE: Character array constructors KEYWORDS: Character, array constructor, zero-size DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The f95 standard appears to leave the length of zero-sized character array constructors undefined. The penultimate paragraph of clause 4.5 says "The type and parameters of an array constructor are those of the expressions." If there are no elements, then the values of the type parameters might not be defined. The type and kind are always well defined at compile time. However, the length parameter for zero-sized character array constructors is not obviously well-defined, even at run-time. Zero-sized constructors are certainly allowed, as mentioned in the antipenultimate paragraph of clause 4.5: "An empty sequence forms a zero-sized rank-one array." Experimentation with different f90 compilers yields varying results. QUESTION 1: Is the following a valid program and, if so, what len value does it print? program zero write (*,*) len( (/ ('abc', i = 1 , 0) /) ) end QUESTION 2: Is the following a valid program and, if so, what value does it print? program zero_size integer :: n = 0 call sub('abcdefghij', n) contains subroutine sub(string, n) character*(*) :: string integer :: n integer :: i write (*,*) len( (/ (string(:i+2), i = 1 , n) /) ) end subroutine end program zero_size QUESTION 3: Is the following a valid program and, if so, what values does it print for the lengths and for n_calls? program zero_size integer :: n = 0 integer :: n_calls = 0 call sub('abcdefghij', n) write (*,*) 'n_calls = ', n_calls contains subroutine sub(string, n) character*(*) :: string integer :: n integer :: i write (*,*) len( (/ (string(:f(i)), i = 1 , n), 'abcde' /) ) end subroutine sub integer function f(i) f = 2*i + 5 n_calls = n_calls + 1 end function f end program zero_size ANSWER: (1) Yes. The length is 3. Clause 4.5 says that "The type and type parameters of an array constructor are those of the expressions." There is no exclusion for s that contribute no elements to the value of the array constructor: thus s that are inside zero-trip implied DO loops still contribute their "type" information. The example array constructor has an that is the character literal 'abc'; this clearly has the character length of 3 and therefore the array constructor has a character length of 3. The description of how an that is an implied DO is handled confuses syntax and semantics: an edit is supplied to clarify this. (2) No. The edits below clarify this situation. (3) Yes. The length printed is 5, n_calls is still zero. Clause 4.5 says that "If the expressions are of type character, each expression in the shall have the same character length parameter." The example array constructor has an that is the character literal 'abcde'; this clearly has the character length of 5 and therefore the array constructor has a character length of 5. No references to the function F are executed because these appear within a zero-trip implied DO loop. EDITS: In clause 4.5, in the paragraph beginning "If an is a scalar expression" [46:1] replace: "an sequence" with "a sequence of elements". In clause 4.5, at the end of the paragraph which begins "If the expressions are of type character" [45:38+], insert: "A zero-sized character array constructor shall have at least one that is an initialization expression, a that does not contain a , or a containing a in which all expressions are initialization expressions." SUBMITTED BY: Richard Maine HISTORY: 98-101 m144 submitted 20 Nov 1997 99-207 m150 additional input 99-217r3 m150 approved uc 00-209 m153 passed by J3 letter ballot m153 duplicated in interp 000071; processing 000016 complete ---------------------------------------------------------------------- NUMBER: 000072 TITLE: Resolving generic procedure references KEYWORDS: generic, ELEMENTAL DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider INTERFACE generic ELEMENTAL SUBROUTINE sub_e(a) REAL,INTENT(INOUT) :: a END SUBROUTINE sub_3(a) REAL,INTENT(INOUT) :: a(:,:,:) END END INTERFACE This is legal (it obeys the restrictions in 14.1.2.3). This allows the ambiguous reference REAL x(10,20,30) CALL generic(x) However, the existing text in 14.1.2.4.1 does not explain which procedure is called, because the reference is consistent with two procedures. Note 14.6 indicates that the intent is to call the nonelemental procedure in this case. Is note 14.6 correct as to the intent of the standard? ANSWER: Yes, note 14.6 is correct; an edit is supplied to the resolution rules to implement this. EDIT: [278:41] After "with" insert "a non-elemental reference to". SUBMITTED BY: Malcolm Cohen HISTORY: 99-218 m150 submitted, approved uc 00-209 m153 passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000073 TITLE: Is padding allowed in storage sequences? KEYWORDS: alignment, padding, storage sequence DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Is padding allowed in storage sequences? Consider the common block CHARACTER C INTEGER I COMMON /CBLK/ C, I Is padding allowed between the variables C and I? Consider the sequence type TYPE T SEQUENCE CHARACTER C INTEGER I END TYPE Is padding allowed between component C and component I? ANSWER: Padding between storage units is allowed unless those storage units are explicitly required to be contiguous in Section 14.6.3.1 or they are required to be contiguous in order to satisfy the storage association rules given in Sections 14.6.3.2 and 14.6.3.3. Discussion: A user recently complained that Sun f90 adds pad for alignment to sequence types and common blocks. He asserted that the Fortran standard forbids padding storage sequences. I have tested seven different implementations, and I found that all but one use padding in the examples given. The user based his assertion on the text of Section 14.6.3.1 of the Fortran 95 standard. He claimed the statements (7) A nonpointer scalar object of sequence type occupies a sequence of storage sequences corresponding to the sequence of its ultimate components and The order of the storage units in such a composite storage sequence is that of the individual storage units in each of the constituent storage sequences taken in succession, ignoring any zero-sized constituent sequences. made his acse. I pointed out that where the standard intends to require storage units to be contiguous, it uses the word "contiguous". He was not satisfied by that answer. The user pointed out that the definition of the size of a storage sequence supports his assertion. He claimed that the size of the common block given above is one character storage unit plus one numeric storage unit, and that that is the size of the common block INTEGER J CHARACTER D COMMON /CBLK/ J,D which Sun f90 does not pad. While that arithmetic of sizes makes sense, I have been told informally by a committee member that that was not the intent of the committee. Note 5.33 lends support to his statement. I have been unable to find any for the first paragraph of Note 5.33 in the normative part of the standard. REFERENCES: ISO/IEC 1539-1:1997(E), Note 5.33 and Section 14.6.3. EDITS: I suggest moving the first paragraph of Note 5.33 to the normative part of the standard. I tried to provide a definition of addition of sizes of different storage units that would imply the effect stated in Note 5.33, but I failed. SUBMITTED BY: Robert Corbett HISTORY: 99-190 m150 submitted, straw vote to allow padding 11-0-0 ---------------------------------------------------------------------- NUMBER: 000074 TITLE: TARGET dummy arguments and POINTER expressions KEYWORDS: TARGET, POINTER, dummy arguments DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Consider the following program. PROGRAM questionable REAL,TARGET :: x CALL s1(f(x)) CALL s2(f(x)) CALL s3(f(x)) CONTAINS FUNCTION f(a) REAL,POINTER :: f REAL,TARGET :: a f => a END FUNCTION SUBROUTINE s1(variable) variable = 42 ! statement 1 END SUBROUTINE SUBROUTINE s2(variable) INTENT(OUT) variable variable = 42 ! statement 2 END SUBROUTINE SUBROUTINE s3(targ) REAL,TARGET :: targ REAL,POINTER :: p p => targ PRINT *,ASSOCIATED(p,x) ! statement 3 END SUBROUTINE END Is this program standard-conforming, and if so, what value is printed? The real question is whether an expression argument that is a pointer function reference is treated as a variable (data-object) argument with the variable being the target of the pointer expression. (Or whether it is dereferenced as usual in the absence of POINTER dummy arguments). Re (statement 1), the question is whether VARIABLE is definable when argument-associated with "F()". Re (statement 2), if the previous answer was Yes (VARIABLE is definable), then presumably it can be made INTENT(OUT). A random sample of 4 compilers revealed that they considered it not to be definable. Re (statement 3), the question is whether P is pointer-associated with X, not pointer-associated with X, or processor-dependent. Of the same random sample 3 thought it was associated with X, 1 thought not. ANSWER: EDIT: SUBMITTED BY: Malcolm Cohen HISTORY: 99-198 m150 submitted ---------------------------------------------------------------------- NUMBER: 000075 TITLE: Defined assignment and INTENT(IN) dummy arguments in PURE procedures KEYWORDS: INTENT(IN), PURE, defined assignment, dummy arguments DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Consider the following module: MODULE m TYPE t REAL,POINTER :: value END TYPE INTERFACE ASSIGNMENT(=) MODULE PROCEDURE t_asgn_t END INTERFACE CONTAINS PURE SUBROUTINE t_asgn_t(lhs,rhs) TYPE(t),INTENT(OUT) :: lhs TYPE(t),INTENT(IN) :: rhs ALLOCATE(lhs%value) lhs%value = rhs%value END SUBROUTINE PURE FUNCTION t_plus_t(a,b) TYPE(t) t_plus_t,a,b INTENT(IN) a,b t_plus_t = a !defined assignment !Alternative: CALL t_asgn_t(a,b) t_plus_t%value = t_plus_t%value + b%value END FUNCTION END According to F95 [212:33-45] "Constraint: In a pure subprogram any variable which ... is a dummy argument to a pure function ... shall not be used in the following contexts: ... (8) As the of an in which the is of a derived type if the derived type has a pointer component at any level of component selection; ..." Therefore it appears that the statement labelled "defined assignment" is not allowed. However, it is semantically equivalent to the commented-out statement in the following line, which would have been allowed. Clearly intrinsic assignment in that context must be disallowed as it implicitly does a pointer assignment which could be used to produce a side-effect, but the standard appears to rule out defined assignment as well (which if pure cannot cause any side-effect). Is this intentional? ANSWER: EDIT: SUBMITTED BY: Malcolm Cohen HISTORY: 99-201 m150 submitted ---------------------------------------------------------------------- NUMBER: 000076 TITLE: INTENT(IN) dummy arguments and implied DO loops KEYWORDS: INTENT(IN), implied DO DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The Fortran 95 standard [53:13-17] says "Constraint: A dummy argument with the INTENT(IN) attribute ... shall not appear as ... (3) A DO variable or implied-DO variable, ..." The apparent intent is to prevent any modification of the dummy argument; however, use in data-implied-do and array-constructor-implied-do would not modify the dummy argument. Is the constraint intentionally stronger than necessary? ANSWER: The constraint is only intended to apply to implied-DO variables in I/O lists. The following edit makes this clearer. EDIT: [53:17] Change "A DO variable or implied-DO variable" to "A in a or ". SUBMITTED BY: Malcolm Cohen HISTORY: 99-199 m150 submitted 99-199r1 m150 approved uc 00-209 m153 passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000077 TITLE: INTENT(IN) dummy arguments and NULLIFY KEYWORDS: INTENT(IN), NULLIFY DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The Fortran 95 standard [53:13-17] says "Constraint: A dummy argument with the INTENT(IN) attribute, or a subobject of such a dummy argument, shall not appear as ... (2) The of a , ..." Consider: TYPE t REAL,POINTER :: value END TYPE ... SUBROUTINE s(x) TYPE(t),INTENT(IN) :: x IF (.FALSE.) x%value => NULL() ! (1) IF (.FALSE.) NULLIFY(x%value) ! (2) According to the constraint above, line (1) is illegal. However, there is no corresponding constraint for the NULLIFY statement, implying that line (2) is legal. Should subobjects of INTENT(IN) dummies also be constrained against appearing as the of a NULLIFY statement? ANSWER: Yes, there should be a constraint disallowing INTENT(IN) dummy arguments in a NULLIFY statement. The edit below corrects this omission. EDIT: Replace constraint (2) with "The in a or ," SUBMITTED BY: Malcolm Cohen HISTORY: 99-200 m150 submitted 99-200r1 m150 approved uc 00-209 m153 passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000078 TITLE: Resolving generic procedure references KEYWORDS: INTENT(IN), NULLIFY DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: 14.1.2.4 (Resolving procedure references) seems to fail to resolve the following example. Consider: INTERFACE sin CHARACTER FUNCTION sinch(c) CHARACTER,INTENT(IN) :: c END END INTERFACE PRINT *,sin(3.5) ! Reference to which procedure? END According to rule (1)(a), SIN is established to be generic; thus references are resolved by the rules in 14.1.2.4.1. In 14.1.2.4.1: Rule (1) fails - the reference is not consistent with any specific interface in the interface block for SIN. Rule (2) fails for the same reason. Rule (3) fails because there is no INTRINSIC statement. Rule (4) fails because there is no host scoping unit. Is this program legal? How should the reference to the generic procedure be resolved? ANSWER: EDIT: SUBMITTED BY: Malcolm Cohen HISTORY: 99-202 m150 submitted ---------------------------------------------------------------------- NUMBER: 000079 TITLE: Pointer Assignment and Allocatable Arrays KEYWORDS: Pointer assignment, allocatable DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot Consider PROGRAM p REAL,ALLOCATABLE,TARGET :: x(:) POINTER p(:) p => x ALLOCATE(x(10)) PRINT *,SIZE(p) END This appears to be a legal program - there seems to be no prohibition against pointer assignment to an unallocated allocatable array and allocating the array does not seem to alter the association status of any pointer associated with an allocatable array. Should there be a prohibition against pointer assignment to an unallocated allocatable array? ANSWER: Yes; an edit is supplied to correct this oversight. EDIT: In clause 7.5.2, at the end of the paragraph that begins "The shall" [111:8+], insert: "If the is an allocatable array, it shall be currently allocated." SUBMITTED BY: Malcolm Cohen HISTORY: 99-223 m150 submitted, approved 6-4 00-209 m153 passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000080 TITLE: Host association and the EXTERNAL attribute KEYWORDS: Host association, EXTERNAL DEFECT TYPE: Erratum STATUS00-208.txt: Passed by J3 letter ballot QUESTION: Use of a (non-intrinsic) name as a procedure in a procedure reference implicitly confers the EXTERNAL attribute on the name. Does this happen when the name is host-associated? For example, f90 interp 143 established that MODULE m1 REAL x CONTAINS SUBROUTINE s PRINT *,x(1) END SUBROUTINE END was invalid - 11.3.2 now says that a "procedure with implicit interface and public accessibility shall explicitly be given the EXTERNAL attribute in the scoping unit of the module". However, this text says nothing about private entities, so considering: MODULE m2 REAL,PRIVATE :: x CONTAINS SUBROUTINE s PRINT *,x(1) END SUBROUTINE END This example does not violate 11.3.2 because X is PRIVATE. Is this example conforming? Further, considering: PROGRAM m3 REAL x CONTAINS SUBROUTINE s PRINT *,x(1) END SUBROUTINE END This example is not of a module and so 11.3.2 does not apply. Is this example conforming? Further, considering PROGRAM m4 EXTERNAL x CONTAINS SUBROUTINE s PRINT *,x(1) END SUBROUTINE END Does the invocation as a function in an internal procedure cause X to be implicitly typed, or is this not conforming? ANSWER: No, use of a host-associated name never confers attributes on the host entity. Examples M2, M3, and M4 are therefore invalid. Edits are supplied. EDIT: [188:28] Delete "and public accessibility". [188:31] Delete "with public accessibility". [283:16+] Add new paragraph after the note "An external or dummy procedure with an implicit interface that is accessed via host association shall explicitly be given the EXTERNAL attribute in the host scoping unit or be used as a procedure in that scoping unit; if it is invoked as a function in the inner scoping unit, its type and type parameters shall be explicitly declared in a type declaration statement in the host scoping unit. An intrinsic procedure that is accessed via host association shall explicitly be given the INTRINSIC attribute in the host scoping unit or be used as an intrinsic procedure in that scoping unit." SUBMITTED BY: Malcolm Cohen HISTORY: 99-230 m151 submitted 99-230r1 m151 approved uc 00-209 m153 passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000081 TITLE: Definition status of derived-type objects with pointer components KEYWORDS: Definition status, Derived type, Pointer component DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Consider: TYPE t REAL,POINTER :: x END TYPE TYPE(t) var1,var2 NULLIFY(var1%x) var2 = var1 ! Unfortunate. According to 14.7.1, "An object is defined if and only if all of its subobjects are defined." from which I conclude that the program fragment above is not conforming. Should the definition status of an object contain pointer components depend on the pointer association status of its pointer components and not their definition status? ANSWER: Yes. Edits are supplied to clarify this situation. EDITS: [288:17] Insert "nonpointer" before "subobjects". Before "." insert "and all of its pointer subobjects have a pointer association status of associated or disassociated". [288:18] Insert "nonpointer" before "subobjects". [288:19] After "undefined" insert "or at least one of its pointer subobjects has a pointer association status of undefined". SUBMITTED BY: Malcolm Cohen HISTORY: 99-266 m151 submitted 99-266r1 m151 approved uc 00-135 m152 revised but withdrawn (no vote), text above still 99-266r1 ---------------------------------------------------------------------- NUMBER: 000082 TITLE: Usage of BOZ literal constants KEYWORDS: BOZ constant DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider: INTEGER X(10) DATA X(B"001")/42/ END This is apparently conforming, since the constraint at [32:15] says "A may appear only in a DATA statement." But this rules out X(B"001") = 42 Is this an error? ANSWER: Yes, BOZ literal constants should be restricted to being a . EDITS: [32:15] Replace text of constraint with "A may appear only as a in a DATA statement." SUBMITTED BY: Malcolm Cohen HISTORY: 99-275 m151 submitted 99-275r1 m151 approved uc 00-209 m153 passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000083 TITLE: Scope of array-constructor implied-DO variable KEYWORDS: Scope, implied DO, array constructor DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: 14.1.3 states that the scope of an implied-DO variable in an array constructor is "the implied-DO list". There is no such syntax term: what is meant? In particular, in the array constructor (/ (I,I=1,I) /) are all three I's references to the implied-DO variable, or is one of them a reference to a variable I in the enclosing scoping unit? ANSWER: All occurences of I within the implied-DO are references to the implied-DO variable, none of them can reference a variable in the enclosing scoping unit. The term "implied-DO list" is confusing in this context; "implied-DO" was intended. An edit is supplied for clarification. DISCUSSION: The term "implied-DO list" is used in several places where the context is that of the values produced by the implied-DO. This is an inappropriate term to use for specifying scope. Also, the second and third occurrences of "I" in the example shown are part of the syntax item . It would be unreasonable to read "implied-DO list" as meaning (for array constructors) " and the in but not the s in ." Note that the problem does not arise for because variables other than implied-DO variables are not permitted in the limit expressions. With this interpretation the example array constructor supplied is not valid Fortran, as it is not permissible to reference the value of an variable in one of its limit expressions. EDITS: [280:41] Replace "implied-DO list" with "implied-DO". SUBMITTED BY: Malcolm Cohen HISTORY: 00-124 m152 Submitted 00-124r1 m152 approved uc 00-209 m153 passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000084 TITLE: Events that cause variables to be defined KEYWORDS: Definition status, INTENT(OUT) DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Item (6) of 14.7.5 says "A reference to a procedure causes the entire dummy argument to become defined if the entire corresponding actual argument is defined with a value that is not a statement label. A reference to a procedure causes a subobject of a dummy argument to become defined if the corresponding subobject of the corresponding actual argument is defined." For an INTENT(OUT) dummy this appears to conflict with 14.7.6 item (13)(b) "When a procedure is invoked ... (b) A dummy argument with INTENT(OUT) is undefined except for any nonpointer direct components of the argument for which default initialization is specified." So in X = 3 CALL S(X) ... SUBROUTINE S(A) INTENT(OUT) A ... Is A defined (with the value 3) in accordance with 14.7.5, or undefined in accordance with 14.7.6? Similarly, for subobjects of INTENT(OUT) dummies, does 14.7.5 take precedence or 14.7.6? ANSWER: A is undefined in accordance with 14.7.6. An edit is supplied to remove the conflict. Similarly, 14.7.6 takes precedence for subobjects. EDITS: [289:9] Before "entire" insert "dummy argument does not have INTENT(OUT) and the". [289:12] Before "corresponding" insert "dummy argument does not have INTENT(OUT) and the". SUBMITTED BY: Malcolm Cohen HISTORY: 00-141 m152 submitted, approved uc 00-209 m153 passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000085 TITLE: Public components of private types KEYWORDS: Accessibility, Derived Types, Components DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: F90 interpretation 32 indicated that components of a derived type may be accessible even in scopes where the derived type name is inaccessible. It added an edit to 12.1.2.2.1 of f90 (14.1.6.3 of f95) saying "If a derived type name of a host is inaccessible, data entities of that type or subobjects of such data entities can still be accessible." The discussions in the last 2 paragraphs of 4.4.1 of f95 appear to treat the accessibility of the derived type and its components as independent issues. Drafts of f2k added a note to make the independence clear. However, 14.1.2.5 of f95 says "If the type is accessible...and the definition of the type does not contain the PRIVATE statement (4.4.1), the component name is accessible...." This statement appears to make accessibility of the type a condition for accessibility of the component names, in contradiction with the above cited edit from f90 interpretation 32. The following code sample illustrates the issue. This sample works on several f90 compilers. module m type t integer :: i end type t type (t) :: a end module m program p use m, only: a a%i = 2 write (*,*) a%i end program p Question 1. Is it allowed to access public components of a derived type object when the type name is inaccessible as illustrated in the above sample code? Question 2. Should there be an edit in 14.1.2.5 of f95 to clarify this? ANSWER: EDIT: SUBMITTED BY: Richard Maine HISTORY: 99-101 m148 Submitted ---------------------------------------------------------------------- ====================================================================== Part 3: Unfinished F90 interpretations with their F90 interp number. ====================================================================== NUMBER: F90/000049 TITLE: Characteristics of function results KEYWORDS: characteristics, function result, ENTRY statement, exact dependence, association - partial, association - entry DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Given a character function with an ENTRY statement, both results must have the same characteristics or be scalars without the POINTER attribute and have identical length. Therefore: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN,ENT ... ENTRY ENT(M,N) ... END FUNCTION is standard conforming. Question 1: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=M+N)::ENT ... ENTRY ENT(M,N) ... END FUNCTION Is the code above standard conforming? Question 2: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=N+M)::ENT ... ENTRY ENT(M,N) ... END Is the code above standard conforming? Question 3: FUNCTION FUN(M) CHARACTER (LEN=M+M)::FUN CHARACTER (LEN=M*2)::ENT ... ENTRY ENT(M) ... END Is the code above standard conforming? Question 4: What is the meaning of the phrase "the exact dependence on the entities" in section 12.2.2? ANSWER: Answer 1. Yes Answer 2. Yes Answer 3. Yes Answer 4. The sentence containing the phrase "the exact dependence on the entities" in section 12.2.2 is intended to convey that in those cases where the shape or character length type parameter is not constant, the corresponding characteristic of the function result is not a value but the way the value is determined when the procedure is invoked. Discussion: Only the mapping from program state to value is significant, not the particular form in which that mapping is expressed. In question 3, for example, it is a characteristic of FUN and ENT that their lengths are twice the value of M. It is not required that the expressions of this mapping be identical, only that they yield the same results. Thus, twice the value of M could be expressed as M+M for FUN and as M*2 for ENT. The phrase "the exact dependence on the entities in the expression is a characteristic" is used to give the processor the freedom to evaluate lengths and bounds in any convenient manner. Since the characteristics must be the same, the phrase implies, as a minimum, that the expressions be algebraically equivalent and use the same variables. In an example such as: FUNCTION FUN(M) CHARACTER (LEN=M)::FUN CHARACTER (LEN=M + 0*K)::ENT ... ENTRY ENT(M, K) ... END FUN and ENT do not have the same characteristics since their dependence on "K" is different. Indeed, if on entry to FUN the length of FUN or ENT were evaluated using the expression for the length of ENT the evaluation would fail since K is not associated with a value. Clearly, it can be extremely difficult to determine on a static basis whether two expressions of a mapping are consistent, and there is no requirement in the standard that this be done. It would be possible to check during execution that the values expressed are identical each time such a procedure is invoked, but it is expected that a more typical application of this requirement would be to assume that it has been met and use one expression of this mapping as the basis for computing attributes of all of the result variables. REFERENCES: ISO/IEC 1539:1991 (E) section 12.2.2 & 14.6.3.3 EDITS: None SUBMITTED BY: Y. Yoshida, X3J3/92-051 (121-ADT-11) pp.-13 HISTORY: 92-109A m121 Approved 19-0 92-313 m123 response to ballot comments and approved by uc 93-105 Revised in response to ballot comments 93-152 m125 New edit, rejected 94-059 m128 New edit, 94-252 m130 New response without edits, approved u.c. 94-306 m131 X3J3 ballot approved 18-1 95-044 m132 WG5 ballot failed, text in Answer 4 and discussion needs revision ---------------------------------------------------------------------- NUMBER: F90/000070 TITLE: Characteristics specified by interface bodies KEYWORDS: characteristics, array bounds, array shape, function result DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Section 12.3.2.2 indicates that an interface body specifies all of a procedure's characteristics and that the characteristics must be consistent with those in the procedure definition. Are the following code fragments standard conforming? (a) PROGRAM FRED INTERFACE SUBROUTINE SUB (ARR,J) INTEGER ARR(1:) END SUBROUTINE END INTERFACE INTEGER ARR(10) CALL SUB(ARR,2) END PROGRAM SUBROUTINE SUB(ARR, J) INTEGER ARR(J:) ... END SUBROUTINE SUB (b) FUNCTION C1( ) CHARACTER(*) C1 ... END FUNCTION C1 FUNCTION C2(N) CHARACTER(N) C2 ... END FUNCTION C2 SUBROUTINE CALLER( ) INTERFACE FUNCTION C1( ) CHARACTER(*) C1 END FUNCTION FUNCTION C2(N) CHARACTER(2) C2 END FUNCTION END INTERFACE CHARACTER(5) CC CC=C1( )//C2(2) ANSWER: (a) This example is standard conforming. (b) This example is not standard conforming. Discussion: (a) 12.2.1.1 states that the characteristics of a dummy data object include its shape, and that if the shape is assumed then that is a characteristic. Section 2.4.5 states that the shape of an array is determined by its rank and extent in each dimension (but not by its bounds, 5.1.2.4.2). Both the interface block for SUB and the definition of SUB describe the shape of ARR as assumed, so they are describing the same shape, and the program is standard conforming. It is possible to read the second sentence in 12.2.1.1 as requiring bounds to match. This was not intended. An edit to that section (defect item 49) has clarified that it is the shape resulting from the bounds specifications that is a characteristic and not the bounds themselves. (b) Section 12.2.2 states that the characteristics of a function include whether or not the function result value is a character of assumed length. So the interface body for function C1 must indicate that C1 is of assumed length. However, item (3) in 5.1.1.5 indicates that scoping units that invoke an external character function of assumed length must have access to a declaration of the function name with a length type parameter value other than *. An edit is included to clarify this restriction. In addition, the interface for C2 does not conform to the standard as the length of C2 specified as 2 is not consistent with the length specified as N within the function definition. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.4.5, 5.1.1.5, 5.1.2.4.2, 12.2.1.1, and 12.2.2. EDITS: In section 5.1.1.5 item (3), add to the end [43:5]: "Note that the interface for such a function cannot be specified in an interface body." SUBMITTED BY: Graham Barber (a), Janice Shepherd (b) HISTORY: 92-264 Question (a) originally posed 92-46 Question (b) originally posed in e-mail collection ui 48 (jw note) 92-283 Response proposed m123 Approved by unanimous consent 93-018 Response questioned by John Reid in 93-103 Revised response proposed m124 Approved by unanimous consent 93-111 m125 ballot, return to subgroup, Leonard comment, coordinate with 0000049? 94-060 m128 New edit in 0000049 referenced ---------------------------------------------------------------------- NUMBER: F90/000096 TITLE: Definition of "Declaration" KEYWORDS: declaration, specification DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: "Declaration" is a significant concept of Fortran 90. Section 5 is titled "Data object declarations and specifications" and what were in FORTRAN 77 "type statements" are now "type declaration statements". 5.1.1 states "A type specifier specifies the type of all entities declared in an entity declaration list." Nowhere, though, is there a definition of "declaration". What does it mean, in Fortran 90, to "declare" something? ANSWER: The edits below add a definition of "declaration" and, for clarity, also add a definition of "specification". Edits related to these definitions are also provided. REFERENCES: EDITS: 1. Replace the text of 2.5.3 "Declaration" [16:13-18] with: A data object declaration specifies the creation, attributes, and lifetime of the object. Every data object must be declared. Declarations can be explicit or contextual. Data object attributes not specified explicitly are determined implicitly. A declaration of a data object of derived type is also a declaration of all of its components. In a scoping unit, if a name appears as: (1) an object-name in an entity-decl in a type-declaration, SAVE, POINTER, or TARGET statement (2) a named-constant in a named-constant-def in a PARAMETER statement (3) an array-name in a DIMENSION or ALLOCATABLE statement (4) a variable-name in a common-block-object in a COMMON statement (5) the name of a variable that is wholly or partially initialized in a DATA statement (6) the name of an object that is wholly or partially equivalenced in an EQUIVALENCE statement (7) a dummy-arg-name in a FUNCTION, SUBROUTINE, ENTRY or statement-function statement (8) a result-name in a FUNCTION or ENTRY statement then those statements constitute an explicit declaration of a data object with that name in that scoping unit. otherwise: if a name that is not a procedure name, module name, program name, generic identifier, common block name, namelist group name, construct name, or derived type name, appears in any statement and that name is not the name of a data object accessed by host or use association then those appearances constitute a contextual declaration of a data object with that name in that scoping unit 2. In section 5.2.9 "DATA statement", in the fifth constraint following R537 [52:31-32]: delete "made accessible by use or host association," as now redundant with the definitions of use and host association. 3. In 11.3.2 "USE statement", in the paragraph beginning "If two or more" in the third sentence [158:29-31]: change: through to: through explicit declaration, 4. In 12.1.2.2.1 "Host association" replace items 5 though 12 with the one new item [164:8-17] (5) An explicitly declared data object (2.5.3); 5. In Annex A, add to page 256 after "datum" [256:10+] Declaration(2.5.3): A declaration specifies the existence of a data object. 6. In Annex A, add to page 260 after "size" [260:14+] Specification: A specification assigns attributes and properties to names. SUBMITTED BY: Dick Weaver HISTORY: 92-232 Submitted 92-232r Draft response, withdrawn 93-144 m125 unanimous consent 93-255r1 m127 ballot failed 16-7 94-103 m128 revised response, approved uc 94-116 m129 X3J3 ballot failed 16-7 94-223 m130 revised response 94-335 m131 alternate response proposed, withdrawn ---------------------------------------------------------------------- NUMBER: F90/000100 TITLE: ASSOCIATED intrinsic and zero-sized objects KEYWORDS: ASSOCIATED intrinsic, zero-sized objects, target, pointer DEFECT TYPE: Interpretation STATUS: J3 approved; ready for WG5 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 edits in defect item 000027 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 is equal to 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 is equal to 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 is equal to 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: None. 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 95-306r1 m135 withdrew edits as defect item 27 supplies better edits, approved u.c. 96- m136 X3J3 ballot, approved 15-1 ---------------------------------------------------------------------- NUMBER: F90/000140 TITLE: TARGET attribute for a derived-type object with a pointer component KEYWORDS: POINTER attribute, TARGET attribute, structure, structure component DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Section 6.1.2 (page 63) states: "A structure component has the INTENT, TARGET, or PARAMETER attribute if the parent object has the attribute." A constraint following R505 (page 40) states: "Constraint: If the POINTER attribute is specified, the TARGET, INTENT, EXTERNAL, or INTRINSIC attribute must not be specified." This would seem to imply that a derived-type object with a pointer component could not have the TARGET attribute. Though it is informative, Annex C.4.6 (page 267) contains the following example: "TYPE CELL INTEGER :: VAL TYPE (CELL), POINTER :: NEXT_CELL END TYPE CELL TYPE (CELL), TARGET :: HEAD TYPE (CELL), POINTER :: CURRENT ... CURRENT => HEAD" which allows the static head of a linked list or tree. Does the structure component HEAD % NEXT_CELL contradict the text cited above from section 6.1.2 or the cited constraint following R505? ANSWER: No, the component reference does not contradict either the constraint or the cited text from 6.1.2. The cited text from 6.1.2 is not needed and an edit provided deletes it. Discussion: The constraints that follow a syntax rule, or a set of syntax rules, are syntactic constraints and apply only to the syntax rules they immediately follow. Thus, the constraints that follow rules R501 through R505 at the beginning of section 5 apply only to those rules. This means they apply only to type declaration statements. Since a derived type component is part of a derived type definition (which is not a type declaration statement), the constraints do not apply to derived type components. The rule that prevents an entity from having conflicting attributes when applied by multiple specification statements is found in 5.2: "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." The sentence from 6.1.2 cited in the question is not necessary (and is thus deleted by an edit) because the "barrier" to a reference or definition of a structure component is at the structure (parent) level and thus no additional "barrier" is needed at the component level. Thus, for example, specifying an attribute such as TARGET at the structure level is sufficient; there is no need to "trickle down" the attribute to components of the structure (and indeed if a component were treated as an independent variable, the combination of TARGET and POINTER would otherwise be prohibited). The philosophy that an attribute applied at the structure (parent) level is all that is needed is borne out by the following: TARGET: Section 7.5.2, second constraint states: "The must have the TARGET attribute or be a subobject of an object with the TARGET attribute ..." PARAMETER: Rule R601 and the constraints associated with it state that neither an nor a can have the PARAMETER attribute and that a must not be a subobject designator whose parent is a constant. INTENT(IN): The response to defect item 135 added a constraint to 5.1.2.3 that states that a dummy argument with the INTENT(IN) attribute, or a subobject of such an object, must not appear in any assignment context. EDIT: In section 6.1.2, in the paragraph following the last constraint [63:15-17], delete the sentence that starts: "A structure component has the INTENT..." SUBMITTED BY: J. Martin in response to email May 7, 1993 from Yukimasa Yoshida HISTORY: 93-179 m125 canceled, interpretation number then reassigned 93-181 m125 Response, Withdrawn to remove suggested edit. 93-223r m126 Response proposed, approved uc 93-255r1 m127 ballot failed 18-5 94-339 m131 Revised response proposed, approved 14-2 95-034r1 m132 X3J3 ballot failed 8-12 95-033 m132 Revised response, straw vote on intent 5-2-7 95-092 m132 Revised discussion, approved u.c. 95-101 m133 X3J3 ballot failed 11-7 ---------------------------------------------------------------------- NUMBER: F90/000145 TITLE: Expressions in of a FUNCTION statement KEYWORDS: expression - specification, expression - initialization, FUNCTION statement, host association, use association DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: The syntax rule R1217 shows that the type and type parameters of a function can be specified in the FUNCTION statement (12.5.2.2). (a) If a appears in a FUNCTION statement, can the initialization and specification expressions of that involve names of entities that are declared within the function or are accessible there by host or use association? (b) Section 5.1 states: "The (7.1.6.2) of a (5.1.1.5) or an (5.1.2.4) may be a nonconstant expression provided the specification expression is in an interface body (12.3.2.1) or in the specification part of a subprogram." As a FUNCTION statement is not part of the specification part of a subprogram, this text in the standard appears to distinguish between FUNCTION statements that are in interface blocks and ones that are not. This text seems to prohibit such examples as: INTEGER I ... CONTAINS CHARACTER*(I+1) FUNCTION F() ... COMMON // I ... where it can be confusing as to which I is being referenced in the FUNCTION statement. While host association does not apply to interface bodies, for consistency should the text quoted from Section 5.1 have been "... is in the specification part of an interface body (12.3.2.1) or in the specification part of a subprogram."? (c) Section 7.1.6.1 states: "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." Was this text intended to apply to FUNCTION statements even though they are not part of any , thus disallowing fragments such as: INTEGER (KIND=KIND(X)) FUNCTION F() INTEGER(KIND=KIND(0)) X ... Similar text appears in Section 7.1.6.2. ANSWER: (a) A specification expression in the of a FUNCTION statement may involve names of entities that are declared within the function or are accessible there by host or use association, but an initialization expression in such a may only involve names that are accessible by host or use association. (b) No. It was not the intent of the standard to distinguish between the two types of FUNCTION statements cited. As elaborated in the discussion of part (a), the standard intended to allow the expression of a FUNCTION statement to be a nonconstant expression. The sentence cited is corrected with a supplied edit. (c) Yes, the text cited from 7.1.6.1 was intended to apply to FUNCTION statements. The sentence quoted and the corresponding sentence in 7.1.6.2 are corrected with supplied edits. The code fragment is not standard conforming. Discussion: (a) An initialization expression is a constant expression with an additional rule relating to exponentiation (7.1.6.1). Since it is a constant expression, the only names it can contain are the names of named constants, structure constructors, intrinsic procedures, and variables whose type parameters or bounds are inquired about. * Named constant Section 5.1.2.1 states: "A named constant must not be referenced in any ... context unless it has been defined in a prior PARAMETER statement or type declaration statement using the PARAMETER attribute, or made accessible by use association or host association." Since the FUNCTION statement is the first statement of the scoping unit, there can be no prior PARAMETER statement or type declaration statement using the PARAMETER attribute, so the first clause does not apply. A named constant can appear in a of a function statement if it is accessible within the function by host or use association. * Structure constructor Rule R502 shows that the only opportunities for expressions to appear in s are in a or in a . However, a structure constructor can not appear in a because rule R505 shows that a must be an integer expression. Similarly, R506 shows that any initialization expression in a must be type integer. Therefore, a structure constructor can not appear in an initialization expression in the of a FUNCTION statement. * Intrinsic procedure The intrinsic procedure names or classes of intrinsic procedures that may appear in an initialization expression are given in 7.1.6.1. * Variables whose type parameters or bounds are inquired about The text from section 7.1.6.1 as cited in question (c) was intended to apply to initialization expressions in the of a FUNCTION statement. With the correction supplied, this means that if a variable appears as the argument to an inquiry intrinsic in the of a FUNCTION statement, the function must be a module procedure or an internal procedure, and the variable must exist in (be accessible from) the host scoping unit. Rule R502 defines . The only opportunity for a to contain a is when the data type is character ( may be a ). Section 7.1.6.2 states that a specification expression is a restricted expression that is scalar, of type integer, and each operation must be intrinsic. In addition, rule (2) of 7.1.6.2 states that a primary of a specification expression can be a dummy argument that has neither the OPTIONAL nor INTENT(OUT) attribute. The following code fragment demonstrates a use of such a dummy argument: CHARACTER*(N+1) FUNCTION S(N) INTEGER, INTENT(IN) :: N Rule (2) also states that the primary can be a subobject of such a dummy argument. Section 6.1.2 indicates that a structure component must not be referenced or defined before the declaration of the parent object. Similar rules are needed to prevent a substring from being referenced ahead of the declaration of its parent, and an array element or array section from being referenced ahead of the declaration of the array. Edits are provided to supply these rules. Since a subobject can not be referenced before its parent object is declared and the FUNCTION statement is the first statement of the subprogram, the parent's declaration could not have occurred. Thus a subobject must not be referenced in the on a FUNCTION statement for objects declared within the function. Rule (3) states that a primary can be a variable that is in a common block. The following code fragment demonstrates a use of such a common block member: CHARACTER*(N+1) FUNCTION S() ... COMMON N As in rule (2), rule (3) allows a subobject of such a variable but for the same reasons as above, such a subobject designator can not appear in the expression of a FUNCTION statement. Rule (4) states that a primary may be a variable that is accessible by use association or host association. The following code fragments demonstrate uses of such variables: PROGRAM MAIN INTEGER :: N = 21 ... CONTAINS CHARACTER(LEN = 2*N) FUNCTION SS(K) ! N is host associated. ... END FUNCTION END PROGRAM and MODULE MOD INTEGER K DATA K /20/ END MODULE CHARACTER*(K*2) FUNCTION CHECK(STR) ! K is use associated. USE MOD ... END FUNCTION Rule (4) also states that the primary can be a subobject of such a use or host associated variable. A structure constructor can not appear in a FUNCTION specification expression because the expression must be of type integer and any operations (which might yield an integer value from one or more structure constructors) must be intrinsic. Other rules of 7.1.6.2 state which intrinsic procedure names or classes of intrinsic procedures may appear in a specification expression. Section 7.1.6.2 also states: A variable in a specification expression must have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit type rules currently in effect for the scoping unit, or by host or use association. The discussion above regarding specification expressions has already ruled out "previous declarations" so the first clause of the cited sentence does not apply. The other clauses apply equally to a FUNCTION statement and to type declaration statements inside the function. (b) When the discussion for part (a) is applied to the code fragment provided, it means that the 'I' referenced in the of the FUNCTION statement is the common block member. EDITS: 1. Section 5.1, in the first sentence of the paragraph that starts "The (7.1.6.2)" [40:39-41], change "in an interface body (12.3.2.1) or in the specification part of a subprogram" to "contained in an interface body (12.3.2.1), is contained in the specification part of a subprogram, or is in the of a FUNCTION statement (12.5.2.2)" 2. Section 6.1.1, add to the end of the paragraph before the examples [62:29] "A substring must not be referenced or defined before the declaration of the type and type parameters of the parent string, unless the type and type parameters are determined by the implicit typing rules of the scope." 3. Section 6.2.2, add after the sentence "An array section is an array." [64:16] "An array element or array section must not be referenced or defined before the declaration of the array bounds." 4. Section 7.1.6.1, in the paragraph after the constraints [78:21-22] change "object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "object declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the initialization expression." 5. Section 7.1.6.2, in the 2nd paragraph after the constraint [79:28-29] change "entity specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "entity declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the specification expression." SUBMITTED BY: Janice C. Shepherd HISTORY: 93-193 m126 submitted 94-023r1 m128 response, approved uc 94-116r1 m129 X3J3 ballot failed 22-1 94-336 m131 revised response, approved u.c 95-034r1 m132 X3J3 ballot failed 15-5 95-281 m135 revised response, reworded edit 3, WG5 approved (N1161) 96- m136 X3J3 ballot failed 15-1, WG5 approval removed. ---------------------------------------------------------------------- NUMBER: F90/000164 TITLE: Use of ONLY with multipart definitions KEYWORDS: ONLY, module, derived type DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Sections 11.3.1 and 11.3.2, among others, describe how accessibility of data objects, derived type definitions, etc. can be controlled via the ONLY clause of the USE statement and via the PUBLIC and PRIVATE accessibility attributes/statements. But these sections do not describe what happens when a definition consists of multiple parts and only some of the parts have their accessibility controlled. Examples include, but are not limited, to the following: Example 1: MODULE MOD INTEGER, PARAMETER :: MAX_SIZE = 100 INTEGER, DIMENSION(MAX_SIZE) :: ARRAY END MODULE PROGRAM MAIN USE MOD, ONLY: ARRAY ... END PROGRAM Since the declaration of ARRAY depends on the value of MAX_SIZE, is it valid to only allow access to ARRAY? Is the array constructor for ARRAY, for example, accessible to the main program? Example 2: MODULE MOD TYPE INNER INTEGER I END TYPE TYPE OUTER INTEGER K TYPE(INNER) COMP END TYPE END MODULE PROGRAM MAIN USE MOD, ONLY: OUTER ... END MODULE The derived type OUTER in module MOD has a component of derived type INNER. However, when the main program accesses the module, it restricts access to only derived type OUTER. Since OUTER depends on the definition of INNER, is it valid to only allow access to OUTER? If it is not valid, is it only an error if something in the main program actually tries to use OUTER? Can you write a structure constructor for OUTER in the main program? If it is valid, can component I of substructure COMP be referenced? Example 3: MODULE MOD TYPE DEF INTEGER K REAL R END TYPE TYPE(DEF) VAR END MODULE PROGRAM MAIN USE MOD, ONLY: VAR ... END MODULE In this example, only the variable VAR from the module is accessible; its type is not. Is this valid? If it is valid, can only the structure name VAR be referenced or can its components also be referenced? If only the structure name VAR can be referenced, what is the meaning when the structure name is included in a namelist object list for input and/or output? Example 4: MODULE MOD INTEGER, PARAMETER :: MAX_SIZE = 100 INTEGER, DIMENSION(MAX_SIZE) :: ARRAY PRIVATE MAX_SIZE END MODULE PROGRAM MAIN USE MOD ... END PROGRAM Another way to limit access to items in modules is via the PRIVATE attribute/statement. Since the declaration of ARRAY depends on the value of MAX_SIZE, is it valid to only allow access to ARRAY? Is the array constructor for ARRAY, for example, accessible to the main program? ANSWER: EDIT(S): SUBMITTED BY: Larry Rolison HISTORY: 94-038 m128 submitted ---------------------------------------------------------------------- NUMBER: F90/000179 TITLE: DO variable with POINTER attribute KEYWORDS: DO variable, POINTER attribute DEFECT TYPE: Interpretation STATUS: J3 approved; ready for WG5 QUESTION: The first constraint following rule R822 states: "Constraint: The must be a named scalar variable of type integer, default real, or double precision real." The definition of loop initiation (8.1.4.4.1) states: "(2) The DO variable becomes defined with the value of the initial parameter 1." The definition of the execution cycle of a DO loop (8.1.4.4.2) states: "(3) ... The DO variable, if any, is incremented by the value of the incrementation parameter 3." Consider the following program: INTEGER, POINTER :: PTR INTEGER, TARGET :: LCV PTR => LCV DO PTR = 1, 3 PRINT *, LCV END DO END Note that the DO variable has the POINTER attribute. The POINTER attribute does not seem to be prohibited for the DO variable, but when the DO variable has the POINTER attribute, it is unclear as to whether the DO variable is the pointer or the target of the pointer. That is, it is unclear as to whether the pointer or the target is to be "defined" (8.1.4.4.1) or incremented (8.1.4.4.2). Also consider the following modification of the above program: INTEGER, POINTER :: PTR INTEGER, TARGET :: LCV1, LCV2 LCV1 = 1 LCV2 = 4 PTR => LCV1 DO PTR = 1, 3 IF (...) PTR => LCV2 ! An alternate EXIT form? END DO END The standard does not seem to address what happens when the DO variable is switched to a different variable while the loop is active. Is it the intent of the standard to permit a DO variable with the POINTER attribute? ANSWER: Yes, a DO variable may have the POINTER attribute. Discussion: There are a number of contexts in the language where the target of a pointer is referenced or defined when it is the pointer name that appears. Two of these are cited in items (2) and (3) in the Question. In (2), the target of the pointer variable is defined with the value of the DO loop initial value parameter. In (3), the target of the pointer variable is incremented. Other examples of these kinds of contexts are: * Section 6.3.1, which describes the ALLOCATE statement: "If the STAT= specifier is present, successful execution of the ALLOCATE statement causes the to become defined with a value of zero." * Section 9.4.1.5, which describes the semantics of the I/O error branch: "(2) If the input/output statement also contains an IOSTAT= specifier, the variable specified becomes defined with a processor-dependent positive integer value," In contexts such as these, the variable involved may have the POINTER attribute and it is the intent of the standard that it is the target of the pointer that is being defined, incremented, etc. With respect to the modified example in the Question, the standard does address what happens when the DO variable appears on the left hand side of a pointer assignment. In the modified example in the Question, the statement IF (...) PRT => LCV2 ! An alternate EXIT form? is prohibited. Section 14.7.6 states: "(18) Execution of a pointer assignment statement that associates a pointer with a target that is defined causes the pointer to become defined." but section 8.1.4.4.2 states: "Except for the incrementation of the DO variable that occurs [when the DO variable is incremented by the value of the incrementation parameter], the DO variable must neither be redefined nor become undefined while the DO construct is active." Thus, since the pointer assignment statement causes the DO variable to become (re)defined, it is prohibited. Similarly, if the modified example had contained within the DO construct an assignment statement such as: PRT = 10 such an assignment statement would also be prohibited because defining the target of a pointer also defines the pointer as stated in section 14.6.2.2: "The definition status of a pointer is that of its target." EDITS: None. SUBMITTED BY: Larry Rolison HISTORY: 94-226r1 m130 submitted, approved 10-1 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot, failed see Cohen's comments 95-246 m134 revised edits, approved u.c. 95-256 m135 X3J3 ballot, failed 10-6 95-304r1 m135 revised response, delete edits, approved u.c. 96- m136 X3J3 ballot, approved 15-1 ---------------------------------------------------------------------- NUMBER: F90/000180 TITLE: Unambiguous generic references KEYWORDS: host association, generic name DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider the following example: SUBROUTINE S() INTERFACE GEN1 FUNCTION F1(I) END FUNCTION FUNCTION F2(I,J) END FUNCTION END INTERFACE INTERFACE GEN2 FUNCTION G1() END FUNCTION FUNCTION G2(I) END FUNCTION END INTERFACE CALL SS() CONTAINS SUBROUTINE SS() INTERFACE GEN1 FUNCTION F3(I,J,K) END FUNCTION FUNCTION F4(II) END FUNCTION END INTERFACE INTERFACE GEN2 SUBROUTINE G3() END SUBROUTINE END INTERFACE A = GEN1(1,2,3) ! CALL TO F3 A = GEN1(1,2) ! CALL TO F2 A = GEN1(1) ! CALL TO F4 CALL GEN2() ! CALL TO G3 END SUBROUTINE END There are rules in section 14.1.2.3 that determine within a scoping unit what procedures can have the same generic specification. These rules directly mention access of a generic procedure via use association, but they make no mention of generic names accessed via host association. There is evidence that the rules in section 14.1.2.3 were not intended to apply to generic interfaces accessed by host association. Section 14.1.2.4.1 indicates that a call to a generic name can be resolved to a generic name in the host if the scoping unit and the host scoping unit both agree that the generic name is the name of a function or a subroutine. This indicates that in the example above, the definition of 'GEN2' is valid, even though 'G1' and 'G2' are functions while 'G3' is a subroutine. If the rules set out in 14.1.2.3 were to apply then the definition of 'GEN2' would be invalid. Do the rules in 14.1.2.3 apply to generic procedures accessed via host association? ANSWER: No. The rules in 14.1.2.3 were intended to apply to only those specific procedures declared to be generic in a scoping unit and those accessed via use association. Edits are included to clarify this. EDITS: 1. Add to the end of the first sentence of section 14.1.2.3 [242:27] "when the generic interfaces for each of the specific procedures are declared in the same scoping unit or accessed via use association." 2. Add to the end of the first paragraph of section 14.1.2.3 [242:32] "When a generic procedure is accessed from a host scoping unit, the steps for resolving a procedure reference as described in 14.1.2.4.1 have the same effect as if the rules restricted which specific versions from the host scoping unit can be accessed via the generic reference." SUBMITTED BY: Janice C. Shepherd HISTORY: 94-239r3 m130 submitted with suggested answer, approved u.c. 94-306 m131 X3J3 ballot, failed 15-4 ---------------------------------------------------------------------- NUMBER: F90/000185 TITLE: What is the allocation status of an array after an allocation failure? KEYWORDS: ALLOCATE, POINTER, DEALLOCATE, status DEFECT TYPE: Interpretation STATUS: J3 approved; ready for WG5 QUESTION: It does not appear that the standard defines the allocation status of an array if an ALLOCATE statement fails and returns a nonzero STAT= value? Given a program segment such as: REAL, ALLOCATABLE, DIMENSION(:) :: A,B,C ALLOCATE(A(10), B(10), C(10), STAT = ISTAT) Question 1: If "ISTAT" comes back non-zero, is it legal to deallocate the arrays and try to reallocate them with smaller sizes? Question 2: If instead of allocatable arrays, the variables had been pointers, is it legal to NULLIFY them? Question 3: Are the answers to questions 1 and 2 different if a single array is allocated rather than a list? Question 4: If a DEALLOCATE fails for a list, what is the allocation status of the arrays? Question 5: Is it acceptable to use the ALLOCATED and/or ASSOCIATED functions to attempt to recover from a failure? Question 6: 6.3.1.1 might be read to mean that successful allocation makes the arrays "currently allocated" and otherwise leaves them "not currently allocated". But that's not an obvious reading of the text. In some ways I/O is similar to allocate (they both process a list of things and have a STAT= clause). If an input statement fails then everything in the list becomes undefined. Does that apply by analogy to ALLOCATE? ANSWER 1: Yes. Note that one or more of the arrays is expected to have an allocation status of "currently not allocated", due to the error which occurred. See the Discussion below. Note that this example only used allocatable arrays. If a pointer appears in a DEALLOCATE statement, its pointer association status must be defined (section 6.3.3.2). See the Discussion below. ANSWER 2: Yes. See section 14.6.2.3. ANSWER 3: No, the answers are the same. See Answer 6 below. ANSWER 4: When a DEALLOCATE with a "STAT=" specifier fails, those arrays that were successfully deallocated will have an allocation status of deallocated. Those arrays not successfully deallocated retain their previous allocation status. ANSWER 5: For ALLOCATED, yes. For ASSOCIATED, it depends on the pointer association status of the pointer at the time the ASSOCIATED intrinsic is called. The ALLOCATED intrinsic may be called with any allocatable array whose allocation status is either currently allocated or currently not allocated. The ASSOCIATED intrinsic must not be called with a pointer whose pointer association status is undefined (section 6.3.3.2). See the Discussion below. ANSWER 6: No. The standard does not require a processor to allocate the variables specified in an ALLOCATE statement as a group; therefore, a processor may successfully allocate some of the arrays specified in an ALLOCATE statement even when that ALLOCATE statement assigned a positive value to the variable specified in the STAT= specifier. Discussion: Only when the allocation status of an array is undefined is it illegal to specify the array in a DEALLOCATE statement. The only way for an allocatable array to have a status of undefined is described in section 14.8, item (3). If an array specified in a DEALLOCATE statement has an allocation status of not currently allocated when the DEALLOCATE statement is executed, an error condition occurs as described in section 6.3.3.1. The behavior of the DEALLOCATE statement in the presence of an error condition is described in section 6.3.3. Immediately after the execution of an ALLOCATE statement, all allocatable arrays specified in that ALLOCATE statement will have a defined allocation status. The arrays that were successfully allocated will have an allocation status of allocated, while any arrays not successfully allocated will retain their previous allocation status. When a pointer is specified in an ALLOCATE statement which fails (assigns a positive value to ISTAT in this example), then the pointer association status of that pointer will not be changed if the allocation failed for that particular pointer. If that pointer previously had a pointer association status of undefined, it will still have a pointer association status of undefined immediately after the ALLOCATE statement is executed; therefore, it would be illegal to specify that pointer in a DEALLOCATE statement (section 6.3.3.2) or in a call to the ASSOCIATED intrinsic (section 13.13.13), unless the allocation status of the pointer was first changed to be defined (either associated or disassociated). EDITS: None. SUBMITTED BY: Dick Hendrickson HISTORY: 94-296 m131 submitted 95-039 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot approved, 12-6 95-310r1 m135 revised response to be consistent with F95, approved u.c. 96- m136 X3J3 ballot approved, 15-1 ---------------------------------------------------------------------- NUMBER: F90/000190 TITLE: Subobjects of constants in a DATA statement KEYWORDS: DATA stmt, constant DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: Consider the following syntax rules from Section 5.2.9: R532 is [*] R533 is ... R534 is and the following constraint Constraint: A of a must involve as primaries only constants or DO variables of the containing s, and each operation must be intrinsic. In all cases, the rules reduce to "constant". The definition of "constant" is provided by R305: R305 is or R307 is The above two rules seem to indicate that if an identifier appears where "constant" is allowed in the DATA statement rules cited above, the identifier must be a name; that is, it can not be the subobject of a named constant. Is this analysis correct? ANSWER: Yes, your analysis is correct. A , a , and a constant appearing in a of a DATA implied-DO can be a name (of a named constant) but not a subobject designator. Discussion: There is no intent in the standard to extend the above rules over what was provided in the FORTRAN 77 standard. So, for example, the following program fragment is not standard conforming: INTEGER, PARAMETER :: PARR(3) = (/ 1, 2, 3 /) INTEGER :: ARRAY(3) DATA (ARRAY(I), I = PARR(1), 3) / PARR(1), PARR(2)*PARR(3) / EDITS: None SUBMITTED BY: Larry Rolison HISTORY: 94-302 m131 submitted, with proposed response 94-360 m131 alternate answer proposed, failed 7-7 94-302 m131 original answer, approved 14-2 95-034 m132 X3J3 ballot failed 15-5 ---------------------------------------------------------------------- NUMBER: F90/000191 TITLE: Interaction of SEQUENCE derived types and rename KEYWORDS: SEQUENCE, derived type, use association, derived type DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider the following: MODULE M TYPE T SEQUENCE TYPE (T), POINTER :: P END TYPE END MODULE USE M, T2=>T TYPE T SEQUENCE TYPE (T2), POINTER :: P END TYPE TYPE (T) X TYPE (T2) Y X = Y END Section 4.4.2, 'Determination of derived types', seems to indicate that types T and T2 in the main program refer to the same type. Note that both types have structure components that agree in order, name, and attributes. However, considering type T in the context of module M only, type T is a derived type that contains one component that is a pointer to itself. In the context of the main program, type T is a derived type that contains one component that is a pointer to a different derived type. Are types T and T2 considered to be the same type? ANSWER: Yes, T and T2 are the same type. An edit is provided to clarify this conclusion. Discussion: The first sentence in section 4.4.2 states, "a particular type name may be defined at once in a scoping unit." However, by the use of rename, it's possible for a scoping to have access to two separately defined derived types, that were originally defined the same name, by two different local names. For derived types made accessible by use association, the derived type name referred to in section 4.4.2 is in the corresponding . Edits are provided to clarify this. EDITS: 1. In section 4.4.2, add the following to the end of the first paragraph: [35:39] "In addition, two derived types accessible in the same scope might be the same if one or both are accessible by use association." 2. In section 4.4.2, after the second paragraph, add the following independent paragraph: [35:46] "Note that the criterion that the two types have the same name applies to the of the respective ." SUBMITTED BY: Janice C. Shepherd HISTORY: 94-273 m130 submitted 94-377 m131 Response submitted, approved u.c. 95-034r1 m132 X3J3 ballot failed 15-5 ---------------------------------------------------------------------- NUMBER: F90/000194 TITLE: Statements between SELECT CASE and CASE KEYWORDS: FORMAT statement, DATA statement, SELECT CASE statement, CASE statement, INCLUDE line, statement order DEFECT TYPE: Interpretation STATUS: J3 approved; ready for WG5 QUESTION: 1. Figure 2.1 (page 11) shows that FORMAT and DATA statements may be intermixed with executable constructs but it is not clear at what points within an executable construct these statements may appear. In particular, may FORMAT and DATA statements appear between the SELECT CASE statement and the first CASE statement of a CASE construct? 2. May an INCLUDE line appear between the SELECT CASE statement and the first CASE statement of a CASE construct? ANSWER: 1. No. In general, FORMAT and DATA statements may appear in the IF, CASE and DO executable constructs because these constructs contain blocks and a block is defined in section 8.1 (on page 95) to consist of s, which in turn are defined as being made up of FORMAT and DATA statements, among others. However, the syntax rules for the CASE construct do not provide for any blocks or any other statements to appear between the SELECT CASE statement and the first CASE statement of a CASE construct. The sentence in 8.1 [95:12] that defines a block in prose introduces the general concept of a block, and does not precisely define the BNF term. The BNF syntax rules give the precise definition. 2. Yes. An INCLUDE line may appear between a SELECT CASE statement and the first CASE statement of a CASE construct because an INCLUDE line is a line, not a statement. EDITS: None. SUBMITTED BY: Larry Rolison HISTORY: 94-383r1 m131 submitted with proposed response, approved 13-3 95-034r1 m132 X3J3 ballot approved 19-1, with edits 95-116 m133 (N1112) correct typo in answer 2. 95-305r1 m135 changed to match F95 approved edits, approved u.c. 96- m136 X3J3 ballot approved 16-0 ---------------------------------------------------------------------- NUMBER: F90/000196 TITLE: Inaccessibility of intrinsic procedures KEYWORDS: intrinsic procedure, INTRINSIC attribute, generic identifier, names class DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Section 14.1.2 states: "Note that an intrinsic procedure is inaccessible in a scoping unit containing another local entity of the same class and having the same name. For example, in the program fragment SUBROUTINE SUB ... A = SIN (K) ... CONTAINS FUNCTION SIN(X) ... END FUNCTION SIN END SUBROUTINE SUB any reference to function SIN in subroutine SUB refers to the internal function SIN, not to the intrinsic function of the same name." Are the following two comments about this text correct? (1) The example is not strictly correct because the resolution of the procedure reference "SIN" depends on the contents of the first "...": (1a) If "..." does not contain an "INTRINSIC SIN" statement, the behavior is as specified: In SUB, the name SIN is established specific due to condition 14.1.2.4 part (2b), it is not established generic, and the internal function SIN is referenced due to 14.1.2.4.2 part (3). (1b) If "..." does contain an "INTRINSIC SIN" statement, SIN is established specific as above, but also established generic due to condition 14.1.2.4 (1b). So the reference is resolved according to 14.1.2.4.1 part (2): the intrinsic function SIN is called. ( At least if there is a suitable specific function for data ) ( object K. If not, the reference is resolved according to ) ( 14.1.2.4.1 (4) which also requires a consistent reference. ) (2) The first sentence of the cited text is wrong (incomplete), because it does not consider the case of generic identifiers: * Intrinsic procedures are local entities of class (1). * Generic identifiers are local entities of class (1). * Various instances in the standard indicate that it is possible to extend the generic interface of intrinsic procedures. Consequently, in the example MODULE my_sin CONTAINS LOGICAL FUNCTION lsin (x) LOGICAL, INTENT(IN) :: x ... END FUNCTION lsin END MODULE my_sin SUBROUTINE sub USE my_sin INTERFACE SIN MODULE PROCEDURE lsin END INTERFACE SIN ... END SUBROUTINE sub the intrinsic procedure SIN remains accessible in SUB although that scoping unit contains another local entity of class (1) named SIN. ANSWER: Comment 1 is incorrect. See the answer to (1b). Comment 1a is correct. Comment 1b is incorrect. SIN is a local name for the internal procedure, which is a specific procedure, and adding an "INTRINSIC SIN" statement is prohibited by 14.1.2, 3rd paragraph. Comment 2 is correct. Edits to remove the contradiction are included below. EDITS: 1.In section 14.1.2, 4th paragraph [241:36], change "having the same name" in the first sentence to "having the same name, except when the other local entity and the intrinsic are both generic procedures" 2.In Section 14.1.2, 3rd paragraph [241:33], change "in the case of" to "when both are" SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: 95-252 m135 submitted 95-281 m135 response WG5 approved (N1161) 96- m136 X3J3 ballot failed 16-0, possible error in 2nd edit, WG5 approval removed. Barber edit applied ---------------------------------------------------------------------- NUMBER: F90/000197 TITLE: Relationship of NEAREST and SPACING KEYWORDS: NEAREST, SPACING, "machine representable" DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: The example in the SPACING intrinsic function description states: SPACING(3.0) has the value 2**(-22) for reals whose model is as at the end of 13.7.1. The example in the NEAREST intrinsic function description states: NEAREST(3.0, 2.0) has the value 3 + 2**(-22) on a machine whose representation is that of the model at the end of 13.7.1. Must the delta computed by NEAREST (the 2**(-22) shown in the example) be the value SPACING would return if given the same (first) argument as passed to NEAREST? ANSWER: Discussion: EDIT(S): SUBMITTED BY: Larry Rolison HISTORY: 95-030 m132 submitted ---------------------------------------------------------------------- NUMBER: F90/000204 TITLE: Meaning of "same variable" description of MVBITS KEYWORDS: MVBITS DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Section 13.13.74 states "TO ... may be the same variable as FROM". Given the following statements, which pairs of variables are the same? INTEGER :: I(10), J(10) EQUIVALENCE (I,J) INTEGER, TARGET :: T(2:11) INTEGER, POINTER :: P1(:), P2(:) P1 => T P2 => T(2:11) I and I P1 and T I(1) and I(1) P1 and T(2:11) I(1:10) and I(1:10) P2 and T I(1:1) and I(1:1:-1) P2 and T(2:11) I and I(1:10) P1 and P2 I and J I(1) and J(1) I(1:10) and J(1:10) I(1:1) and J(1:1:-1) I and J(1:10) ANSWER: Discussion: EDITS: SUBMITTED BY: /jor in response to IBM public comments HISTORY: 95-299 m135 submitted ---------------------------------------------------------------------- NUMBER: F90/000205 TITLE: Restrictions on EXTERNAL KEYWORDS: EXTERNAL attribute, external subprogram DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Let the following two procedures not be contained within a main program, a module, or another subprogram. In this case they are <>s by the definitions of Fortran 90, section 2.2: SUBROUTINE subroutine_subprogram ( ) ! ... END SUBROUTINE subroutine_subprogram FUNCTION function_subprogram ( ) INTEGER :: function_subprogram ! ... END FUNCTION function_subprogram They are also external procedures, since F90 section 2.2.3.1 (and 12.1.2.2) states that "An <> is a procedure that is defined by an external subprogram or by means other than Fortran." External functions may be given the EXTERNAL attribute in form of an (R503), external procedures may be given the EXTERNAL attribute by an (R1207) [F95: R1208]. QUESTION 1: Is it correct that the current definitions in F90 do allow the EXTERNAL attribute to be specified for the name of the external subprogram in which such a declaration is contained? In other words, is the following code standard-conforming? SUBROUTINE subroutine_subprogram ( ) EXTERNAL subroutine_subprogram ! ... END SUBROUTINE subroutine_subprogram FUNCTION function_subprogram ( ) INTEGER, EXTERNAL :: function_subprogram ! ... END FUNCTION function_subprogram QUESTION 2: If the answer to question 1 is YES: was this the intention, or should it be prohibited that an EXTERNAL attribute is given to the name of an external subprogram by declarations within that subprogram? ANSWER: EDIT: SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: 96- m136 submitted ---------------------------------------------------------------------- NUMBER: F90/000206 TITLE: Collating sequence inconsistencies KEYWORDS: Collating sequence, ACHAR, CHAR, ICHAR DEFECT TYPE: STATUS: J3 consideration in progress [F95 CD 36:28+] says that "A <> is a one-to-one mapping of the characters into the nonnegative integers such that each character corresponds to a different nonnegative integer." QUESTION 1: Does this definition imply that the one-to-one mapping is dense? That is, is there a requirement that if the default CHARACTER type has characters, the corresponding collating sequence maps to 0..-1 ? QUESTION 2: If the answer to question 1 is NO: is it correct that the restriction 0 <= i <= -1 on argument I of the intrinsic procedure CHAR (13.14.19) is inappropriate? QUESTION 3: If the answer to question 1 is NO: is it correct that the description of the <> of the intrinsic procedure ICHAR (13.14.45), 0 <= ICHAR(C) <= -1 is inappropriate? QUESTION 4: Shouldn't argument I of the intrinsic procedure ACHAR (13.14.2) be restricted to the nonnegative integers? ANSWER: EDIT: SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: submitted Feb. 17, 1996 (first appeared in 96-006r2) ---------------------------------------------------------------------- NUMBER: F90/000207 TITLE: Integer bit-model inconsistency KEYWORDS: Bit manipulation procedures, models for integer data DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Is the following observation true? [F90 185:last sentence of 13.5.7] and [WG5/N1176, 219:22+] says ``In particular, whereas the models are identical for w_{z-1}=0, they do not correspond for w_{z-1}=1 and ...'' This statement assumes r==2 in the model for integer data defined in 13.7.1, it is not true for general r. The above sentence should be changed to something like ``In particular, whereas the models are identical for r=2 and w_{z-1}=0, they do not correspond for r/=2 or w_{z-1}=1, and ...'' ANSWER: EDIT: SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: submitted Mar. 12, 1996 (first appeared in 96-006r2) ---------------------------------------------------------------------- NUMBER: F90/000208 TITLE: nonadvancing output followed by list directed output KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Section 10.8.2, last sentence. If nonadvancing output is followed by list-directed output, is a blank required before the first character written? (I assume that if the first character of the current record is not a blank, list-directed output is not required, though possibly permitted, to replace that character with a blank.) ANSWER: EDIT: SUBMITTED BY: Robert Paul Corbett (robert.corbett@Eng.sun.com) HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) ---------------------------------------------------------------------- NUMBER: F90/000209 TITLE: STOP|PAUSE in I/O statement KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Section 9.7. May a function referenced in an I/O statement execute a STOP or PAUSE statement? If STOP statements are permitted, what is the state of the file at the end of execution? ANSWER: EDIT: SUBMITTED BY: Robert Paul Corbett (robert.corbett@Eng.sun.com) HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) ---------------------------------------------------------------------- NUMBER: F90/000210 TITLE: nonadvancing write followed by list directed write KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: If a program does a nonadvancing WRITE followed by a list-directed WRITE, must the list-directed WRITE write to the current record or may it start a new record? For what it's worth, CRI f90 starts a new record. ANSWER: EDIT: SUBMITTED BY: Robert Paul Corbett (robert.corbett@Eng.sun.com) HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) ---------------------------------------------------------------------- NUMBER: F90/000211 TITLE: Multiple MODULE PROCEDURE specs KEYWORDS: MODULE PROCEDURE, generic interface, USE association DEFECT TYPE: STATUS: J3 consideration in progress WG5/N1176 (X3J3/96-007) says [194:21-23]: "Constraint: A in a shall not be one which previously had been specified in any with the same generic identifier in the same specification part." QUESTION: 1. Is it correct that this constraint does not preclude the following? MODULE foo1 INTERFACE generic_spec MODULE PROCEDURE proc1 END INTERFACE CONTAINS SUBROUTINE proc1 END SUBROUTINE proc1 END MODULE foo1 MODULE foo2 USE foo1 INTERFACE generic_spec MODULE PROCEDURE proc1 END INTERFACE END MODULE foo2 Although foo2 clearly violates the uniqueness conditions in 14.1.2.3, it seems that it does not violate a Constraint. (Actual compilers do not seem to detect this form of violation of 14.1.2.3 at compile-time.) 2. If the answer to (1) is YES, wouldn't it be sensible to extend that constraint to cases where a "previous" specification of in a with the same generic identifier in the specification part of an accessible module had occurred, _and_ that and generic-spec have PUBLIC accessibility? Probably the wording might be quite complicated because of the possibility of s if FOO1 and s in FOO2, but the essence should be straightforward... The situation in (1) is very similar to the following example, which _is_ detected as erroneous by the compilers I tried: MODULE foo1 CONTAINS SUBROUTINE proc1 END SUBROUTINE proc1 END MODULE foo1 MODULE foo2 USE foo1, ONLY: proc1 USE foo1, ONLY: proc2 => proc1 INTERFACE generic_spec MODULE PROCEDURE proc1 MODULE PROCEDURE proc2 END INTERFACE END MODULE foo2 In both cases, the specific s (and the ) are accessible in MODULE foo2, and the interfaces are explicit anyway. ANSWER: EDIT: SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: submitted Apr. 12, 1996 (first appeared in 96-006r2) ---------------------------------------------------------------------- NUMBER: F90/000212 TITLE: EQUIVALENCE of Data Objects of Different Types or Kinds KEYWORDS: EQUIVALENCE limitations DEFECT TYPE: STATUS: J3 consideration in progress Section 5.5.1 acknowledges that it is possible to construct equivalences between data objects of different types or kinds: "If equivalenced objects have differing type or type parameters, the EQUIVALENCE statement does not cause type conversion or imply mathematical equivalence." [56:35-36] However, section 5.5.1 also has severe restrictions on equivalences between data objects of differing types and kinds. Following rule R547, there are a series of constraints. Constraints 3 through 6 read: Constraint: If an is of type default integer, default real, double precision real, default complex, default logical, or numeric sequence type, all of the objects in the equivalence set must be these types. Constraint: If an is of type default character or character sequence type, all of the objects in the equivalence set must be of these types. Constraint: If an is of a derived type that is not a numeric sequence or character sequence type, all of the objects in the equivalence set must be of the same type. Constraint: If an is of an intrinsic type other than default integer, default real, double precision real, default complex, default logical, or default character, all of the objects in the equivalence set must be of the same type with the same kind type parameter value. Question 1) Why are these constraints in the standard? What useful purpose do they serve? What problems do they prevent or solve? Question 2) Could a standard-conforming processor relax or eliminate one or more of these constraints, as an extension, without sacrificing full conformance to the standard? Question 3) Can a data object of sequence derived type be equivalenced to another data object of a different sequence derived type? Assume that a processor has among its intrinsic types INTEGER (1) (8 bits), INTEGER (2) (16 bits), and INTEGER (4) (32 bits). Given the following definitions, is the EQUIVALENCE statement standard conforming? TYPE T1 SEQUENCE INTEGER (1) I1_ARRAY (36) END TYPE TYPE T4 SEQUENCE INTEGER (4) I4_ARRAY (9) END TYPE TYPE (T1) OBJECT_1 TYPE (T4) OBJECT_4 EQUIVALENCE (OBJECT_1, OBJECT_4) Question 5) Can an object of sequence derived type be equivalenced to an array of intrinsic type? Assume the definitions of question 3. Is the following EQUIVALENCE statement standard conforming? INTEGER (4) :: I4_ARRAY_9 (9) EQUIVALENCE (OBJECT_1, I4_ARRAY_9) Question 6) Can an object of sequence derived type be equivalenced to a scalar of intrinsic type? ANSWER: EDIT: SUBMITTED BY: Craig Dedo (Craig.Dedo@mixcom.com) HISTORY: submitted Jan. 23, 1996 (first appeared in 96-006r2) ---------------------------------------------------------------------- ====================================================================== Part 4: Interpretation Requests of Japan ====================================================================== NUMBER: JP-4 TITLE: Construction of derived-type values KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-4) 4.4.4 Construction of derived-type values Before NOTE 4.34: "Where a component in the derived type is a pointer, the corresponding constructor expression shall evaluate to an object that would be an allowable target for such a pointer in a pointer assignment statement(7.5.2)." Change `an object' to `a result value'. A value of an expression can not be an object, by definition. ANSWER: Change `an object' to `a result value'. A value of an expression cannot be an object, by definition. EDIT: In Clause SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. ---------------------------------------------------------------------- NUMBER: JP-5 TITLE: Construction of array values KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-5) 4.5 Construction of array values, "The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear as the ac-do-variable of the containing ac-implied-do." This sentence should be a Constraint. ANSWER: EDIT: SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. ---------------------------------------------------------------------- NUMBER: JP-6 TITLE: Type declaration statements KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-6) 5.1 Type declaration statements As for the 16th and 19th constraint after R506: the 16th: "Constraint: The function-name shall be the name of an external function, an intrinsic function, a function dummy procedure, or a statement function." Because the syntactic class `object-name' is only defined as a `name' in the standard, the following constraint should be added here: Constraint: The object-name shall be the name of a data object. After that, in the 19th: "Constraint: initialization shall not appear if object-name is dummy argument, a dummy argument, a function result, an object in a named common block unless the type declaration is in a block data program unit, an object in blank common, an allocatable array, an external name, an intrinsic name, or an automatic object." In the above, `a function result,' should be removed. If we can not add the constraint above, `a statement function' should be added in the 19th constraint. ANSWER: EDIT: SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. ---------------------------------------------------------------------- NUMBER: JP-8 TITLE: Type declaration statements KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-8) 5.1 Type declaration statements After NOTE 5.3: "If a length-selector (5.1.1.5) is a nonconstant expression, ..." Change `length-selector' to `char-selector', `char-len-selector' or `character-length'. ANSWER: EDIT: SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. ---------------------------------------------------------------------- NUMBER: JP-12 TITLE: Bounds of each dimension of an array pointer KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-12) 5.1.2.4.3 (2) after R518 (Page 55 Line 41) states that: "(2) They are specified in a pointer assignment statement. ..." In this description, the term "pointer assignment statement" should be changed to "pointer assignment". Reason : The bounds of each dimension of an array pointer may be specified not only in a pointer assignment statement but also in a derived-type intrinsic assignment statement with a component of an array pointer. ANSWER: EDIT: SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. ---------------------------------------------------------------------- NUMBER: JP-16 TITLE: Multiple occurrence of namelist-group-name in NAMELIST statement KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-16) 5.4 2nd paragraph after R545 and constraints (Page 66 Line 11) states that: "Any namelist-group-name may occur in more than one NAMELIST statement in a scoping unit." Can a namelist-group-name occur more than once in one NAMELIST statement ? Is the following NAMELIST statement standard conforming ? NAMELIST /NLIST/ A, B /NLIST/ C, D If this is standard conforming, is it the same as the following ? NAMELIST /NLIST/ A, B, C, D ANSWER: EDIT: SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. ---------------------------------------------------------------------- NUMBER: JP-17 TITLE: Multiple occurrence of namelist group object in namelist group KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-17) 5.4 3rd paragraph after R545 and constraints states that: "A namelist group object may be a member of more than one namelist group." Can a namelist group object occur more than once in one namelist group? Is the following NAMELIST statement standard conforming? NAMELIST /NLIST/A,B,A ANSWER: EDIT: SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. ---------------------------------------------------------------------- NUMBER: JP-24 TITLE: The bnf term shared-term-do-construct KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-24) In 8.1.4.2, second constraint below R833 states that: "The do-term-shared-stmt shall be identified with a label and all of the label-do-stmts of the shared-term-do-construct shall refer to the same label." This implies a label-do-stmts of the outer-most outer-shared- do-construct will permit not to refer to the same label, because shared-term-do-construct does not include outer-most outer- shared-do-construct. So the term "shared-term-do-construct" should be changed to "inner-share-do-construct and outer-shared-do-construct." ANSWER: EDIT: SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. ---------------------------------------------------------------------- NUMBER: JP-31 TITLE: Signs of literal constants KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-31) The fourth sentence of 10.8 and sixth sentence of 10.9: "Each value is either a null value or one of the forms: c r*c r* where c is a literal constant or a nondelimited character constant and r is an unsigned, nonzero, integer literal constant." "a literal constant" should be "an optionally signed literal constant" ANSWER: Add the phrase, "if integer or real" to that last phrase above. EDIT: SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. ---------------------------------------------------------------------- NUMBER: JP-39 TITLE: Note 12.20 KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: JP-39) Page 204/ line 17 (NOTE 12.20): In 6.3.3.2, "If a pointer is currently associated with an allocatable array, the pointer shall not be deallocated". So "DEALLOCATE (B)" would NOT be permitted. ANSWER: EDIT: SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation.