J3/05-015 Completed Fortran 95 Interpretations, October 25, 2005 Stan Whitlock for /interp > includes the F95 interps that would be in an F95 Corrigendum #3 if > there were such a corrigendum, ie, they are passed by WG5 ballot > and done [keep this text document to 70 characters per line]................... Table of Contents Part 0 contains the summary status of all of the Fortran interpretations Part 2 contains F95 interpretation 000000e (typographical interps), interpretations 1-32 and 66-103 Part 3 contains the remaining F90 interpretations left over, with their F90 interp numbers (prefixed with "F90/") All of these are being interpreted against F95. Part 4 contains the Japanese interpretations with their Japanese numbers (JP-4 etc.). These are F95 interpretations. ---------------------------------------------------------------------- ====================================================================== Part 0: Summary Status of these Fortran Interpretations ====================================================================== Note N: d == done {if S = C1 | C2 | T1 then done is assumed} * == active W == would go in F95 Corrigendum 3 if there were one 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 F95 corrigendum 1 (see N1422) C2 Included in F95 corrigendum 2 (see N1473) T1 Included in F03 corrigendum 1 (see N1636/N1640) X Excluded for the reasons given N S T number title - - - ------ ----- d P I 000000e Rejected Minor edits and corrections d W I 000004 Value returned by MAXVAL/MINVAL d W I 000006 Character length specification of a function result d W I 000008 Optional arguments to MAX/MIN d W I 000017 Characteristics of an array function result d W I 000023 Termination of the previous record by a WRITE statement W T1 E 000030 Ordering requirements on definition of specification functions d W I 000068 Asterisks as I/O units W T1 E 000078 Resolving generic procedure references W T1 E 000096 End-of-record and PAD W W E 000099 STAT= variable requirements in ALLOCATE W W E 000100 TARGET attribute and structure components W W E 000101 Generic resolution W W E 000103 Derived type name DOUBLEPRECISION d W I 000104 Representation method of result of REAL d W I F90/000049 Characteristics of function results d W I F90/000070 Characteristics specified by interface bodies d W I F90/000096 Definition of "Declaration" d W I F90/000140 TARGET attribute for a derived-type object with a pointer component d W I F90/000180 Unambiguous generic references d W I F90/000206 Collating sequence inconsistencies W T1 E F90/000207 Integer bit-model inconsistency d W I F90/000208 nonadvancing output followed by list directed output d W I F90/000210 nonadvancing write followed by list directed write d W I JP-17 Multiple occurrence of namelist group object in namelist group W W E JP-24 The bnf term shared-term-do-construct ---------------------------------------------------------------------- ====================================================================== 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 - done 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: Passed by WG5 ballot - done 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). 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. NOTE: The NO votes in 00-254 were concerned that IEEE Infinities are not model numbers and are therefore not valid results for MINVAL and MAXVAL. The IEEE 754 standard is neither integrated into nor required by Fortran 95. However concessions were made to allow some IEEE exceptional values to be used by standard-conforming processors, like limited support for -0.0. EDITS: None. SUBMITTED BY: Larry Rolison HISTORY: 97-240 m143 submitted 00-160r2 m153 Passed 7-5 00-254 m154 Failed J3 letter ballot 04-298r1 m168 Passed J3 meeting vote 04-417r1 m170 Passed J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ------------------------------------------------------------ NUMBER: 000006 TITLE: Character length specification of a function result KEYWORDS: character, function result DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot - done 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 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. NOTE: The NO votes in 01-380 raised the concern that this answer introduced a binary incompatibility with FORTRAN 77. FORTRAN 77 features continue to work in Fortran 95; Fortran 95 features may not always work in FORTRAN 77. EDITS: None SUBMITTED BY: Larry Rolison HISTORY: J3/97-242 m143 submitted WG5-N1456 Draft answer 01-305r1 m158 Passed by J3 meeting 01-380 m159 Failed J3 letter ballot 04-299r1 m168 Passed J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000008 TITLE: Optional arguments to MAX/MIN KEYWORDS: intrinsic function, MAX, MIN, optional, argument DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot - done 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 of Fortran 95 [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: There is an anomaly in the presentation of MAX and MIN but the intent is clear, ie, dummy arguments A3 and beyond are optional. EDITS: None NOTE: The same descriptive form reported here in Fortran 95 appears in Fortran 2003 for MAX and MIN. SUBMITTED BY: Larry Rolison / Dick Hendrickson HISTORY: 97-245 m143 submitted 04-300r1 m168 Passed J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000017 TITLE: Characteristics of an array function result KEYWORDS: Characteristics, function DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot - done 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: No. According to Corrigendum 1, the correct statement is now: "If a bound of a function result array is not an initialization expression, the exact dependence on the entities in the expression is a characteristic of the function result." EDITS: None REFERENCES: 95-006a, F90/000027, F90/000049 & F90/000070, 04-295, N1416 (Corrigendum 1). SUBMITTED BY: Robert Paul Corbett HISTORY: 98-114 submitted 04-313 m168 Passed J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000023 TITLE: Termination of the previous record by a WRITE statement KEYWORDS: Nonadvancing, Record termination, WRITE DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot - done 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 of Fortran 95 [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. Yes. The remaining characters in the record are preserved. Consider the following different, but related, example: program write_write write (10,"(a,t1,a,a)") "XXXXXXXXX", "ABC", "DEF" write (10,"(a,t1,a)",advance='no') "XXXXXXXXX", "ABC" write (10,"(a)") "DEF" end The output from this program is ABCDEFXXX ABCDEFXXX From the description of Position editing (10.6.1) it is clear that the output following the tab does not cause the deletion of the final XXX characters from the record. The fact that the second output record is created by a non-advancing write followed by an advancing write is not operationally different from the single advancing write that created the first record. The fundamental difference between this example and the question considered in the interp is the mechanism by which the current location in the record is established prior to the final advancing write statement. It would be inconsistent to have one case preserve previously existing characters in the record and the other case to require the opposite. To avoid this inconsistency, the answer to Question 2 is Yes. EDITS: None 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 04-301 m168 Passed J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000030 TITLE: Ordering requirements on definition of specification functions KEYWORDS: Specification expressions, specification functions DEFECT TYPE: Erratum STATUS: F95: Passed by WG5 ballot; Included in F03 corrigendum 1 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: No, it is not the intent that the above program unit be standard conforming. The required complexity of implementation is not justified. The standard has no prohibition against it, but the lack of such a prohibition was an oversight. The edits below correct this oversight. EDITS: Add the following new paragraph immediately before Note 7.14: If an initialization expression in a module includes a reference to a generic, that generic shall have no specific procedures defined in the module subsequent to the initialization expression. Add the following new paragraph immediately before Note 7.16: If a specification expression in a module includes a reference to a generic, that generic shall have no specific procedures defined in the module subsequent to the specification expression. SUBMITTED BY: Henry Zongaro HISTORY: 98-176 m146 Submitted 04-312R1 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: 000068 TITLE: Asterisks as I/O units KEYWORDS: Asterisk, I/O, unit DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot - done 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. Not addressed by Fortran 95. 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. 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 file [139:8-9]. 3. Fortran 95 does not specify the behavior in this instance. REFERENCES: ISO/IEC 1539-1:1997(E), Sections 9.3 and 9.4.4.2 EDITS: None 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 01-380 m159 Failed J3 letter ballot 04-306r1 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000078 TITLE: Resolving generic procedure references KEYWORDS: INTENT(IN), NULLIFY DEFECT TYPE: Erratum STATUS: F95: Passed by WG5 ballot: Included in F03 corrigendum 1 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: This program was intended to be valid. The reference is to the intrinsic SIN. An edit is supplied to clarify this. DISCUSSION: (1) INTERFACE OPERATOR(+) does not hide the intrinsic operator. (2) CHARACTER SIN does not hide the intrinsic function. Given that, it would seem perverse for INTERFACE SIN to completely block the intrinsic. Indeed, according to interp F90/000054 the intrinsic is still accessible in this kind of situation. Furthermore, it is clear from the original version of Fortran 90 that a user generic was not intended to hide the intrinsic. This text was modified by interpretation F90/000083 which allowed the user to override an intrinsic function by providing a specific function with the same argument characteristics. The failure of the current 14.1.2.4.1 to resolve the above example was an inadvertent side-effect of that change. EDITS: [279:36+] Append new paragraph "If (1), (2), (3) and (4) do not apply, the name is that of an intrinsic procedure, and the reference is consistent with the interface of that intrinsic procedure, then the reference is to that intrinsic procedure." {Note: This edit made to Fortran 2003 in WG5/N1620 is made as item (5), not as a new paragraph. In 05-182r1, a "," follows "(3)".} SUBMITTED BY: Malcolm Cohen HISTORY: 99-202 m150 submitted 04-296r1 m168 Passed J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: 000096 TITLE: End-of-record and PAD KEYWORDS: End-of-record, PAD DEFECT TYPE: Erratum STATUS: F95: Passed by WG5 ballot; Included in F03 corrigendum 1 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: The situation can only arise for list items of complex type, because list items of derived type are processed as if their components had appeared as list items -- see [149:8-10]. It is clear from text at [150:15] and [153:13] that blanks are not supplied for more than one list item. So the answer to part (3) of the question is "no". Since the texts at [150:15] and [153:13] also refer to a single format item, this leaves the answer to parts (1) and (2) of the question ambiguous: Is it one list item, or one edit descriptor? The answer is that enough blanks are supplied by the processor to satisfy all of the edit descriptors for a list item. EDITS: 97-007r2 [150:15] Replace "corresponding data edit descriptor" by "its corresponding data edit descriptors". [153:13-14] Replace "corresponding data edit descriptor" by "corresponding data edit descriptors". SUBMITTED BY: Van Snyder HISTORY: 01-340 m158 submitted 04-303 m168 Passed by J3 meeting vote 04-417r1 m170 Pass by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: 000099 TITLE: STAT= variable requirements in ALLOCATE KEYWORDS: ALLOCATE, STAT= DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot - done 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(:) INTRINSIC DIGITS I = 5 ALLOCATE(P(DIGITS(I)),STAT=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 ." {The equivalent edits appear in Fortran 2003 04-007 [111:26-28].} SUBMITTED BY: Malcolm Cohen HISTORY: 02-232 m162 Submitted 02-232r1 m162 Revised, passed by J3 meeting 03-197 m165 Passed by J3 letter ballot #7 03-218 m165 Passed by WG5 ballot ---------------------------------------------------------------------- NUMBER: 000100 TITLE: TARGET attribute and structure components KEYWORDS: TARGET, POINTER DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot - done 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 attribute." [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.} {The equivalent edits appear in Fortran 2003 04-007 with the rewrite of chapter 6.] SUBMITTED BY: Malcolm Cohen HISTORY: 02-233 m162 Submitted 02-233r1 m162 Revised, passed by J3 meeting 03-197 m165 Passed by J3 letter ballot #7 03-218 m165 Passed by WG5 ballot ---------------------------------------------------------------------- NUMBER: 000101 TITLE: Generic resolution KEYWORDS: generic, argument DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot - done QUESTION: Consider: INTERFACE g SUBROUTINE s1(p) INTERFACE SUBROUTINE p END END INTERFACE END SUBROUTINE s2(p) INTERFACE REAL FUNCTION p() END END INTERFACE END END INTERFACE EXTERNAL procedure CALL g(procedure) The generic interface block seems to satisfy the requirements of 14.1.2.3, in that s2 has more arguments of type REAL than has s1, but since the data type of "procedure" is not known (it may be a default REAL function, or it may be a subroutine), the CALL appears to be ambiguous. Is this code standard-conforming? ANSWER: No, this was not intended to be standard-conforming. An edit is supplied to correct this oversight. EDITS: [277:21-23] Change "arguments" to "data objects" three times. {The equivalent edits appear in Fortran 2003 04-007 [408:5-7].} SUBMITTED BY: Malcolm Cohen. HISTORY: 02-251 m162 Submitted, passed by J3 meeting 03-197 m165 Passed by J3 letter ballot #7 03-218 m165 Passed by WG5 ballot ---------------------------------------------------------------------- NUMBER: 000103 TITLE: Derived type name DOUBLEPRECISION KEYWORDS: Derived type DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot - done QUESTION: Consider: TYPE doubleprecision REAL x END TYPE According to 4.4.1, the name of a derived type "shall not be the same as the name of any intrinsic type defined in this standard" ([38:34-35]). However, the intrinsic types are only "integer", "real", "complex", "logical" and "character" (4.3, [31:2-4]). Therefore this derived type definition would appear to be allowed. Was it intended to allow a derived type to be named DOUBLEPRECISION? ANSWER: No, this was not intended. An edit is provided to correct this inadvertent omission. EDITS: [38:34] Before "the same" insert "DOUBLEPRECISION or". {The equivalent edits appear in Fortran 2003 04-007 [45:14].} SUBMITTED BY: Malcolm Cohen HISTORY: 03-242 m165 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: 000104 TITLE: Representation method of result of REAL KEYWORDS: "Representation method" KIND REAL DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot - done QUESTIONS: Subclause numbers refer to 97-007r2. The second and third sentences of subclause 4.3.1.2 are A processor shall provide two or more approximation methods that define sets of values for data of type real. Each such method has a representation method and is characterized by a value for a type parameter called the kind type parameter. 1. Does this imply that there is a one-to-one correspondence between kind type parameter values and representation methods? Since the second quoted sentence says "a value," not "some values," assume the answer to this question is "yes." Subclause 7.1.4.2 specifies the type and kind type paramter value for the result of an operation. 2. Is a processor allowed to use a representation method that corresponds to a different kind type parameter value of the same type, or no kind type parameter value, at least if neither the precision nor exponent range of the different representation method is less than the one specified in 7.1.4.2? Subclause 7.1.4.1 specifies the type and kind type paramter value for a variable. 3. Is a processor allowed to use a representation method that corresponds to a different kind type parameter value of the same type, or no kind type parameter value, at least if neither the precision nor exponent range of the different representation method is less than the one specified in 7.1.4.1? Subclause 7.1.4.1 specifies the type and kind type parameter value for a result of a function. 4. Is a processor allowed to use a representation method that corresponds to a different kind type parameter value of the same type, or no kind type parameter value, at least if neither the precision nor exponent range of the different representation method is less than the one specified in 7.1.4.1? Subclause 13.14.28 specifies that the result of DBLE is the same as the result of REAL with a KIND argument having the value KIND(0.0d0). Subclause 13.14.88 specifies that the kind type parameter value of the result of REAL is that specified by the KIND argument. 5. Is a processor allowed to use a representation method for the result that corresponds to a different kind type parameter value of the same type, or no kind type parameter value, at least if neither the precision nor exponent range of the different representation method is less than the one specified in 13.14.88? ANSWER: The answer to question 1 is yes, since each valid real kind type parameter value characterizes a representation method for an approximation method (4.3.1.2). Clause 1.4 says '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, ...' The processor is therefore free to use different precision for intermediate real calculations, which answers all the other questions. EDITS: None SUBMITTED BY: Van Snyder HISTORY: 04-283 m168 submitted 04-307 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- ====================================================================== 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: Passed by WG5 ballot - done 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 006Ar1 m168 Passed by J3 meeting vote as in 02-006Ar1 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000070 TITLE: Characteristics specified by interface bodies KEYWORDS: characteristics, array bounds, array shape, function result DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot - done 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. (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 *. This is explained in Note 5.6, (which has been removed in Fortran 2003). 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: None 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 F90/000049 referenced 04-295 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000096 TITLE: Definition of "Declaration" KEYWORDS: declaration, specification DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot - done 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: That is correct, the standard does not define the term "declaration". It is used both in the sense of explicit specification, and of implicit declaration via usage or context. Both of these meanings fall within the normal English meaning of the term. The suggestion that the standard should define the term "declaration" may be considered for a future revision of the standard. EDITS: None. 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 04-309 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- 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: Interpretation STATUS: Passed by WG5 ballot - done 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 has been clarified by F95 interpretation 000100. 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." EDITS: None. SUBMITTED BY: J. Martin in response to email May 7, 1993 from Yukimasa Yoshida HISTORY: 93-179 m125 canceled, interp 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 04-310 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000180 TITLE: Unambiguous generic references KEYWORDS: host association, generic name DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot - done 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: Yes. [277:12-14] in Fortran 95 explains that the rules apply for all accessible generic interfaces, including those accessible by host association. The example program is not valid. EDITS: None. SUBMITTED BY: Janice C. Shepherd HISTORY: 94-239r3 m130 submitted with suggested answer 94-306 m131 X3J3 ballot, failed 15-4 04-308r1 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000206 TITLE: Collating sequence inconsistencies KEYWORDS: Collating sequence, ACHAR, CHAR, ICHAR DEFECT TYPE: interpretation STATUS: Passed by WG5 ballot - done [F95 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 << Result Value>> 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? ANSWERS: (1) Yes. In the context of Fortran the character collating sequence is an ordered list of the characters in the character set associated with a list of integers denoting the position of each corresponding character in the ordered list of characters. The position number 0 is associated with the first character in the list. As position numbers, the list of integer values is necessarily dense. These position numbers are referenced in the descriptions of the CHAR and ICHAR intrinsic functions. The position numbers may be, but are not necessarily, equivalent to the bit patterns used to represent the associated characters in the computer hardware. (2) Moot because the answer to (1) is Yes. (3) Moot because the answer to (1) is Yes. (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. EDITS: 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 04-304 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000207 TITLE: Integer bit-model inconsistency KEYWORDS: Bit manipulation procedures, models for integer data DEFECT TYPE: Erratum STATUS: F95: Passed by WG5 ballot; Included in F03 corrigendum 1 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: The integer model in 13.7.1 describes integer values using a signed-magnitude, base r representation. The bit model in 13.5.7 describes a method for characterizing a sequence of bits. The two models do not generally correspond and the final sentence of 13.5.7 is defective. EDITS: [219:22-24] Remove the sentence beginning "In particular..." 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 01-380 m159 Failed J3 letter ballot 04-305r1 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 05-182r1 m172 Added to F03 Corrigendum 1 N1636 ---------------------------------------------------------------------- NUMBER: F90/000208 TITLE: nonadvancing output followed by list directed output KEYWORDS: Nonadvancing, list directed DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot - done 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: Following the non-advancing output operation, the location for the start of the next output operation is within the current record. The list-directed output operation begins at this location. List-directed output is an advancing output operation. Following the list-directed output the file position is after the just-written record. If the location for the start of the list-directed output operation is at the beginning of the record, a blank is written to the first location. Otherwise, no characters are inserted between the end of the non-advancing output and the start of the list-directed output. EDITS: 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 04-314 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- NUMBER: F90/000210 TITLE: nonadvancing write followed by list directed write KEYWORDS: Nonadvancing, list directed DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot - done 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? ANSWER: The list-directed WRITE is not required to start a new record. DISCUSSION: Following the non-advancing output operation, the location for the start of the next output operation is within the current record. The list-directed output operation begins at this location. New records may be created during processing of the list-directed output statement. EDITS: 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 04-315 m168 Passed by J3 meeting vote 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ---------------------------------------------------------------------- ====================================================================== Part 4: Interpretation Requests of Japan ====================================================================== NUMBER: JP-17 TITLE: Multiple occurrence of namelist group object in namelist group KEYWORDS: NAMELIST DEFECT TYPE: Interpretation STATUS: Passed by WG5 ballot - done 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 03-197 m165 Passed by J3 letter ballot #7 03-218 m165 Passed by WG5 ballot ---------------------------------------------------------------------- NUMBER: JP-24 TITLE: The bnf term shared-term-do-construct KEYWORDS: DO, BNF DEFECT TYPE: Erratum STATUS: Passed by WG5 ballot - done 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. EDITS: [127:29.5] Replace "" by " and ". {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.} {The equivalent edits appear in Fortran 2003 04-007 [166:6-7].} 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 03-197 m165 Passed by J3 letter ballot WG5-N1561 Request from WG5 to reconsider 03-238 m165 Passed by J3 meeting 04-417r1 m170 Passed by J3 letter ballot #8 05-180 m172 Passed by WG5 ballot N1617 ----------------------------------------------------------------------