J3/02-006A Outstanding Fortran 95 Interpretations, 21 July 2002 Stan Whitlock for /interp [keep this text document to 70 characters per line] 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 C1 Included in corrigendum 1 (see N1422) C2 Included in corrigendum 2 (see N1473) X Excluded for the reasons given S T number title - - ------ ----- P I 000000e Rejected Minor edits and corrections C1 I 000001 Visibility of a data object with statement scope C2 I 000002 Free source form requirement for blank in PRINT statement C1 I 000003 Ability to overload the character operator // P I 000004 Value returned by MAXVAL/MINVAL C1 I 000005 Value returned by SELECTED_REAL_KIND M I 000006 Character length specification of a function result C2 I 000007 Optional intrinsic function arguments P I 000008 Optional arguments to MAX/MIN C2 I 000009 INTENT of MOLD argument to TRANSFER C2 E 000010 Meaning of embedded blanks in namelist input name C2 E 000011 G editing typo C2 E 000012 Evaluation of Intrinsic Procedures X 000013 Format of zero in list-directed and namelist output {questions duplicated in 000067} C2 000014 Format of complex numbers in list-directed and namelist output C2 000015 Commas in list-directed output X 000016 Completely removed - duplicate of 000071 P I 000017 Characteristics of an array function result C2 E 000018 ELEMENTAL procedures with no arguments C2 E 000019 Result of NULL intrinsic associated with CHARACTER(*) dummy argument C2 E 000020 Execution of a WHERE statement within a WHERE construct C2 E 000021 Restrictions on on END INTERFACE C2 E 000022 Use of NULL() as initialization P E 000023 Termination of the previous record by a WRITE statement C2 E 000024 Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement C2 E 000025 List-directed input: types of variables corresponding to repeated values C2 I 000026 List-directed input: types of variables corresponding to repeated values C2 C 000027 Sequential formatted I/O: position of the left tab C2 C 000028 Implicitly Typed Statement Function Character Dummy C2 C 000029 Association of a pointer actual argument with a dummy argument P 000030 Ordering requirements on definition of specification functions M E 000031 Association of pointer function result with INTENT(OUT) dummy argument C2 000032 Is the TRANSFER function result undefined? C2 E 000066 Errors in processing data transfer statements C2 E 000067 Writing zeros M E 000068 Asterisks as I/O units C1 E 000069 What is a numeric character? C1 E 000070 Asymmetry between constant specification and initialization expressions C2 E 000071 Character array constructors C1 E 000072 Resolving generic procedure references C2 000073 Is padding allowed in storage sequences? P 000074 TARGET dummy arguments and POINTER expressions C2 000075 Defined assignment and INTENT(IN) dummy arguments in PURE procedures C1 E 000076 INTENT(IN) dummy arguments and implied DO loops C1 E 000077 INTENT(IN) dummy arguments and NULLIFY P 000078 Resolving generic procedure references C1 E 000079 Pointer Assignment and Allocatable Arrays C1 E 000080 Host association and the EXTERNAL attribute C2 E 000081 Definition status of derived-type objects with pointer components C1 E 000082 Usage of BOZ literal constants C1 E 000083 Scope of array-constructor implied-DO variable C1 E 000084 Events that cause variables to be defined C2 E 000085 Public components of private types C2 E 000086 Definition status requirements for defined operations C2 E 000087 MOD and MODULO intrinsic functions with zero divisor C2 E 000088 INTRINSIC statement and attribute C2 C 000089 Rules allowing duplicate names C2 E 000090 What do `Prior Specification' and `defined previously' mean? C2 E 000091 Definition of "present" is defective C2 E 000092 Values of the PAD= Specifier in the INQUIRE Statement C2 E 000093 Allocatable arrays as actual arguments C2 E 000094 NULL intrinsic in initialization expressions C2 E 000095 Names of functions, results and entry points P I 000096 End-of-record and PAD C2 E 000097 Open Scratch File Example P 000098 Are dummy functions returning assumed-length character legal? P 000099 STAT= variable requirements in ALLOCATE P 000100 TARGET attribute and structure components P I F90/000049 Characteristics of function results P E F90/000070 Characteristics specified by interface bodies P E F90/000096 Definition of "Declaration" C1 I F90/000100 ASSOCIATED intrinsic and zero-sized objects 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 C2 C F90/000164 Use of ONLY with multipart definitions C1 I F90/000179 DO variable with POINTER attribute P E F90/000180 Unambiguous generic references C1 I F90/000185 What is the allocation status of an array after an allocation failure? C2 I F90/000190 Subobjects of constants in a DATA statement C2 I F90/000191 Interaction of SEQUENCE derived types and rename C1 I F90/000194 Statements between SELECT CASE and CASE ??STATUS: J3 approved; ready for WG5 C2 C F90/000196 Inaccessibility of intrinsic procedures C2 F90/000197 Relationship of NEAREST and SPACING C2 E F90/000204 Meaning of "same variable" description of MVBITS C2 E F90/000205 Restrictions on EXTERNAL P F90/000206 Collating sequence inconsistencies M E F90/000207 Integer bit-model inconsistency P F90/000208 nonadvancing output followed by list directed output C2 E F90/000209 STOP|PAUSE in I/O statement P F90/000210 nonadvancing write followed by list directed write C2 E F90/000211 Multiple MODULE PROCEDURE specs C2 C F90/000212 EQUIVALENCE of Data Objects of Different Types or Kinds C2 E JP-04 Construction of derived-type values C2 I JP-05 Construction of array values C2 E JP-06 Type declaration statements C2 E JP-08 Type declaration statements C2 JP-12 Bounds of each dimension of an array pointer C2 E JP-16 Multiple occurrence of namelist-group-name in NAMELIST statement M E JP-17 Multiple occurrence of namelist group object in namelist group M E JP-24 The bnf term shared-term-do-construct C2 E JP-31 Signs of literal constants X JP-39 Withdrawn by submitter ====================================================================== 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 .............' at [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: 000004 TITLE: Value returned by MAXVAL/MINVAL KEYWORDS: MAXVAL, MINVAL DEFECT TYPE: Interpretation STATUS: J3 consideration in progress 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 00-254 m154 Failed J3 letter ballot ------------------------------------------------------------ NUMBER: 000006 TITLE: Character length specification of a function result KEYWORDS: character, function result DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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 reject the reference to FUNC in subroutine SUB and some do not. The implementations that do not reject 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: Yes. When item (1) on page 51 is applied to the argument func of sub, it tells us that its length is 8 for the call from the main program. EDITS: None SUBMITTED BY: Larry Rolison HISTORY: J3/97-242 m143 submitted WG5-N1456 Draft answer 01-305r1 m158 Passed by J3 meeting ---------------------------------------------------------------------- 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: 000013 TITLE: Format of zero in list-directed and namelist output KEYWORDS: DEFECT TYPE: STATUS: Excluded from further processing - answered in 000067 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: These questions are duplicated in interpretation number 000067. See the answer to that query: this was considered an oversight in F95 but would not be fixed by an interpretation. It has been fixed in F2K. HISTORY: 97-165 m143 Submitted WG5/N1410 Draft answer 02-006A m162 Excluded from further processing ---------------------------------------------------------------------- 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: 000023 TITLE: Termination of the previous record by a WRITE statement KEYWORDS: Nonadvancing, Record termination, WRITE DEFECT TYPE: Erratum 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: 1. No. If the current record were to be terminated, the file position would be changed. Section 9.2.1.3.2 [136:37-39] states: "For sequential access on input, if there is a current record, the file position is not changed. Otherwise, the file is positioned at the beginning of the next record and this record becomes the current record." 2. No, the remaining characters in the record are not preserved. The characters are inaccessible. An edit to section 9.2.1.3.2 to clarify the situation is given below. EDIT: [136:44] Change "record becomes" to "record, excluding any data beyond the current point, becomes" SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 1) WG5/N1410 Draft answer 01-151r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Failed J3 letter ballot ---------------------------------------------------------------------- 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: Erratum STATUS: Passed J3 meeting 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: The program does not conform to the Standard. 12.4.1.1 [201:19-21] requires the actual argument to be definable and a function result is not definable. For example, it is not permitted on the left-hand side of an assignment statement, since it is not a variable. The edits add additional text to make this clear. EDITS: In subclause 5.1.2.3, on line 3 of the paragraph that starts 'The INTENT(OUT)' [53:31], add 'a variable that is' before 'definable'. In subclause 5.1.2.3, on line 3 of the paragraph that starts 'The INTENT(INOUT)' [53:36], add 'a variable that is' before 'definable'. In subclause 5.1.2.3, add at the end of the last paragraph [53:38] 'The dummy argument is not definable unless the actual argument is a variable that is definable.'. In subclause 12.4.1.1, on line 20 of page 201 [201:20], add 'a variable that is' before 'definable'. SUBMITTED BY: Henry Zongaro HISTORY: 98-177 m146 Submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 01-200 m157 Passed by J3 meeting 10-2 ---------------------------------------------------------------------- NUMBER: 000068 TITLE: Asterisks as I/O units KEYWORDS: Asterisk, I/O, unit DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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; it is, however, permissible. An edit is provided to clarify this. 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]. 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 it as on any other unit. Note however that a processor extension may have two units connected to the same file - e.g. unit 6 and the * output unit might both identify the user's display device. This is not detectable by a standard-conforming program, but in this case closing unit 6 would not necessarily affect output to the display device via *. 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 00-268 m154 Failed WG5 letter ballot (N1395 & N1403) WG5/N1452 Suggested revision (expanded discussion) 01-296r1 m158 Passed by J3 meeting ---------------------------------------------------------------------- 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: 1. The call to s1 is not standard conforming. 12.5.2.1 says: 'A dummy data object whose intent is not specified is subject to the limitations of the data entity that is the associated actual argument. That is, a reference to the dummy data object may occur if the actual argument is defined and the dummy data object may be defined if the actual argument is definable.' Here the actual argument is a function result, which is not definable. For example, it is not permitted on the left-hand side of an assignment statement, since it is not a variable. 2. The call to s2 is not standard conforming. 12.4.1.1 says: 'If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable.' Again the actual argument is a function result, which is not definable. 3. The call to s3 is standard conforming and the pointer assignment in s3 causes p and x to become associated. This may be deduced from 12.4.1.1, which says [200:38-42]: 'If the dummy argument has the TARGET attribute and is either scalar or is an assumed-shape array, and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure ...' EDITS: None. SUBMITTED BY: Malcolm Cohen HISTORY: 99-198 m150 submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed 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: 000096 TITLE: End-of-record and PAD KEYWORDS: End-of-record, PAD DEFECT TYPE: Interpretation STATUS: J3 consideration in progress Subclause 9.4.3 specifies: If an end-of-record condition occurs during execution of a nonadvancing input statement, the following occurs: if the PAD= specifier has the value YES, the record is padded with blanks (9.4.4.4.2) to satisfy the input list item and corresponding data edit descriptor that require more characters than the record contains; There appears to be a problem if a list item does not correspond to exactly one edit descriptor. QUESTION: If an End-of-record condition occurs during execution of a nonadvancing input statement and the PAD= specifier has the value YES (1) do enough blanks get supplied for the next data edit descriptor and whatever part of the list item corresponds to that edit descriptor, or (2) do enough blanks get supplied for the remainder of the list item and as many edit descriptors as necessary, or (3) do enough blanks get supplied to process the rest of the input list? ANSWER: EDITS: SUBMITTED BY: Van Snyder HISTORY: 01-340 m158 ---------------------------------------------------------------------- NUMBER: 000098 TITLE: Are dummy functions returning assumed-length character legal? KEYWORDS: DUMMY FUNCTION, ASSUMED-LENGTH CHARACTER DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Are dummy functions returning assumed-length character legal? Consider the following program: character*5 f external f call ss3(f) end subroutine ss3(ff) character*(*) ff, a*10 external ff a = ff()//'99999999' print *, '<', a, '>' end function f() character*(*) f f = '123' end The issue is the call to the dummy function 'ff' in subroutine 'ss3'. Some compilers issue an error message. Others print the result: <123 99999> There appear to be two relevant, contradictory passages in the F95 standard. Refer to section 5.1.1.5. <> means italics, [] means obsolescent font. The third constraint says "A function name shall not be declared with an asterisk [unless it is the name of the result of an external function or the name of a dummy function.] Before note 5.6 on the next page, the third bullet says: (3) [In an external function, the name of the function result may be specified with a character length parameter value of *; in this case, any scoping unit invoking the function shall declare the function name with a character length parameter value other than * or access such a definition by host or use association. When the function is invoked, the length of the result variable in the function is assumed from the value of this type parameter.] According to the standard, the use in the example program is legal, because 'ff' is the name of a dummy function. But it seems clear that the standard intended that the length of the variable returned by a character function be known at compile time; it is not known in the case where the function is a dummy function. ANSWER: EDITS: SUBMITTED BY: Larry Meadows HISTORY: 02-157 m160 Submitted ---------------------------------------------------------------------- NUMBER: 000099 TITLE: STAT= variable requirements in ALLOCATE KEYWORDS: ALLOCATE, STAT= DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: [79:40-41] says "The shall not appear in a bound in the same ALLOCATE statement." This requirement appears, on the face of it, to apply to the syntax, not to whichever actual variable is identified by the syntax. Question 1: Given INTEGER :: A(10) = (/ (i,i=1,10) /) POINTER P(:) READ *,I,J ALLOCATE(P(A(I)),STAT=A(J)) Is the ALLOCATE standard-conforming, or does it depend on the relative values of I and J? From the quoted text, it would appear that it is always conforming, even when I==J. Question 2: Similarly, given: EQUIVALENCE(I,J) POINTER P(:) I = 5 ALLOCATE(P(I),STAT=J) is the ALLOCATE conforming? Question 3: Similarly, given: POINTER P(:) I = 5 ALLOCATE(P(DIGITS(I))) is the ALLOCATE conforming? From the quoted text, it would appear not to be conforming, despite the non-dependence of the array bound on the value of the STAT= variable. ANSWER: The intent was that the restriction should apply to the actual variable being used for the STAT= variable, not to the syntax. Thus, (1) The ALLOCATE statement is only standard-conforming if I and J are not equal. (2) The ALLOCATE statement is not standard-conforming. (3) The ALLOCATE statement is standard-conforming. Edits to the standard are supplied to clarify this. EDITS: [79:40-41] Delete "The ... statement." [80:6] Append to paragraph "No array bound in an ALLOCATE statement shall depend on the value of the ." SUBMITTED BY: Malcolm Cohen HISTORY: 02-232 m162 Submitted ---------------------------------------------------------------------- NUMBER: 000100 TITLE: TARGET attribute and structure components KEYWORDS: TARGET, POINTER DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: The standard says ([110:43-44]), of R737 , "Constraint: The shall have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it shall have the POINTER attribute." It also says ([75:22-23]), of structure components "A structure component has the ... TARGET ... attribute if the parent object has the attribute." The <> is defined ([75:16]) as "the data object whose name is the leftmost part name". Consider: TYPE t REAL x END TYPE TYPE(t),POINTER :: p REAL,POINTER :: q ALLOCATE(p) q => p%x Q1. Is this standard-conforming? If the answer to Q1 is Yes, this still appears to leave unspecified the case of A%B%C where A does not have the TARGET attribute and B has the POINTER attribute. The parent object of A%B%C is just A, and A does not have the TARGET attribute. Therefore the conclusion is that A%B%C does not have the TARGET attribute. Note: Although the standard says that "Allocation of a pointer creates an object that implicitly has the TARGET attribute" [81:47-48], is it not entirely sure that this shows that A%B%C has the attribute for two reasons: (1) Allocation is not the only way of establishing pointer associations. (2) According to the quoted text, whether A%B refers to an object with the TARGET attribute is immaterial; the only question is whether A itself has the TARGET attribute. Q2. Does this A%B%C have the TARGET attribute? Note: the following example may be relevant: TYPE t TYPE(t2),POINTER :: p END TYPE TYPE(t2) REAL x END TYPE TYPE(t) v TYPE(t2),POINTER :: z REAL,POINTER :: q ALLOCATE(v%p) ! ! (a) ! z => v%p q => z%x ! ! (b) ! q => v%p%x The pointer assignments following (a) are clearly valid: the first assigns one pointer to another, and if the answer to Q1 is Yes, the second one follows from that. But the (a) statements have the same effect as the (b) statement, so it would be inconsistent to disallow (b). Q3. Apparently, substrings never have the INTENT, TARGET or PARAMETER attribute. Is this a deliberate omission? ANSWER: Q1: Yes. P points to an object with the TARGET attribute, and X is a subobject of this object. Therefore, "Q => P%X" is conforming. Q2: The standard leaves this case unspecified, but the intent is that any part of an object with the TARGET attribute should itself have the attribute. An edit is supplied to remedy this omission in the standard. Q3: No, this omission was inadvertant. An edit is supplied to fix this. EDITS: [74:33] Append to paragraph "A substring has the INTENT, TARGET or PARAMETER attribute if its parent has the attribute, but it never has the POINTER attribute." {Fix omission. Text parallels that for array elements and sections.} [75:22] Delete ", TARGET,". [75:23] After "." insert "A structure component has the TARGET attribute if the parent object has the attribute or if any except the rightmost has the POINTER attibute." [110:43-44] Delete "be a subobject of an object with the TARGET attribute or it shall have". {Now that propagation of TARGET is fixed, we don't need the weasel words.} SUBMITTED BY: Malcolm Cohen. HISTORY: 02-233 m162 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 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/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/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/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: (1) No, the definition in isolation would not require a "dense" mapping. However, in conjunction with the requirements on the CHAR and ICHAR intrinsic functions, the mapping is required to be "dense". (2) No, they are part of the specification of the required mapping. (3) No. (4) No. For characters that are not part of the ASCII character set, IACHAR returns a processor-dependent value that need not be in the ASCII collating sequence. ACHAR, being the inverse of IACHAR, should accept such values. EDIT: None. SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: submitted Feb. 17, 1996 (first appeared in 96-006r2) WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot ---------------------------------------------------------------------- NUMBER: F90/000207 TITLE: Integer bit-model inconsistency KEYWORDS: Bit manipulation procedures, models for integer data DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: Yes. DISCUSSION: If the radix is 10 (e.g. for BCD machines) it is simply not possible for the models to be the same. For a 2-digit BCD machine, the 13.7.1 model gives a number range of +/-99; ignoring the (irrelevant) negative numbers, the bit model either has more numbers (128) or fewer numbers (64) than the BCD model (100). Given this irreconcilable incompatibility, it is best to let the bit intrinsics manipulate the bits and not attempt to pretend that the models can ever match. This allows bit manipulation to be efficient on such machines, but loses the connection between the "normal" value and the "bit" value (which must be at least partially lost no matter how inefficient we make it). EDITS: [219:23] Insert "r=2 and" at the beginning of the line, and Insert "r/=2 or" after "for" (where "/=" is the "not equal" symbol). SUBMITTED BY: Michael Hennecke HISTORY: submitted Mar. 12, 1996 (first appeared in 96-006r2) WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5/N1452 Suggested revision 01-292 m158 Passed by J3 meeting 11-1 ---------------------------------------------------------------------- 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: No. DISCUSSION: If the list-directed WRITE does not start a new record before output of the first list item, it need not output a blank. [178:24] states "each output record begins with a blank". If the first character of the current record is not a blank, the processor must ensure that compliance with [178:24] is achieved by beginning a new record before the output of any list item. EDIT: None. SUBMITTED BY: Robert Paul Corbett (robert.corbett@Eng.sun.com) HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot ---------------------------------------------------------------------- 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: The processor may start a new record whenever it deems it necessary, subject to the restrictions at [177:34-36], which states "The processor may begin new records as necessary ..." This includes at the beginning of a list-directed WRITE. EDIT: None. SUBMITTED BY: Robert Paul Corbett HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot ====================================================================== Part 4: Interpretation Requests of Japan ====================================================================== NUMBER: JP-17 TITLE: Multiple occurrence of namelist group object in namelist group KEYWORDS: NAMELIST DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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: Yes. DISCUSSION: Sections 5.4 "NAMELIST Statement" and 10.9 "Namelist Formatting" in Fortran 95 do not disallow multiple occurrences of a namelist group object in a namelist group. This is also true in Fortran 90. Therefore the multiple occurrences are standard conforming. EDITS: None. SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 01-300 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Failed WG5 ballot 02-130 m160 Change "no" to "yes": Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: JP-24 TITLE: The bnf term shared-term-do-construct KEYWORDS: DO, BNF DEFECT TYPE: Erratum STATUS: Passed by J3 meeting 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." DISCUSSION: There is a typographical error in the question - "8.1.4.2" should read "8.1.4.1.2". The following amplification of the question was provided at the August 2000 WG5 meeting: The present BNF does not preclude the following as a single construct: do 10 i=1,5 ! outer do 20 j=1,5 ! outer do 20 k=1,5 ! outer do 20 l=1,5 ! inner ... 20 continue ! shared ANSWER: Agreed. There is a minor change in the suggested replacement text. EDIT: [127:29.5] Replace "" by "". {The intention is to alter the second line of the second constraint following R833. The line numbering is awry in the F95 copy being used.} SUBMITTED BY: Japan HISTORY: 99-208 m150 Submitted 99-221 m150 Classified as Fortran 95 interpretation WG5-N1411 Aug-2000 Draft answer 02-131r1 m160 Passed unanimously by J3 meeting