PC File: 95-006b2.150 Archive: 95-006r2.B150 -------------------------------------------------------------------------------- NUMBER: 000150 TITLE: Undefinition of implied-DO variables in I/O statements KEYWORDS: i/o statement, implied-DO variable, defined, definition, undefined DEFECT TYPE: Erratum STATUS: Published QUESTION: Section 9.4.3 (in two places) states that when a condition such as an error condition, an end-of-file condition, or an end-of-record condition occurs, execution of the I/O statement terminates and "any implied-DO variables become undefined". Section 14.7.6, item (6) states that when any of these conditions occur, "some or all of the implied-DO variables may become undefined" and references 9.4.3. It appears the intent of the standard was that all implied-DO variables in an I/O statement in which such a condition occurs become undefined. Is that the intent of the standard? ANSWER: Yes. An edit is supplied to make the wording express this intent in both sections 9.4.3 and 14.7.6. Discussion: In several of the draft versions of Fortran 90, specifiers appeared in various I/O statements with values that depended on knowing exactly how an I/O list had been processed prior to the occurrence of an error condition. Late in the development of the standard, the committee realized that no value can be relied upon when an error occurs, and no assumptions can be made about how the I/O list has been processed. Such specifiers were removed but some related text was apparently overlooked. The standard can make no assumptions about how an implementation will process an I/O statement so it can not make any assumptions about which implied-DO variables could conceivably be still defined. Consider the following READ statement: READ *, (A(I), I = 1, 5), (B(J), J = 1, 5) If J was defined prior to the READ statement and if one of the cited conditions occurred while the first implied-DO was "active", the standard could not make the assumption that J remained defined because it could be impossible for the program or I/O system to determine that it was the first implied-DO that was active. EDITS: 1. Section 9.4.3, second paragraph following the numbered list [124:44], change any implied-DO variables become undefined to if the input/output statement contains any implied-DOs, all of the implied-DO variables in the statement become undefined 2. Section 9.4.3, second-to-last paragraph [125:7-8], change any implied-DO variables become undefined to if the input statement contains any implied-DOs, all of the implied-DO variables in the statement become undefined 3. Section 14.7.6, item (6) [251:43-45], change input/output statement, some or all of the implied-DO variables may become to input/output statement and the statement contains any implied-DOs, all of the implied-DO variables in the statement become SUBMITTED BY: Larry Rolison HISTORY: 93-243 m127 submitted 93-300 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000151 TITLE: Defined Operators with POINTER Operands KEYWORDS: defined operator, pointer DEFECT TYPE: Interpretation STATUS: Published QUESTION: Is it the intent of the standard that operators with pointer operands are disallowed or is this an oversight that requires correction? Consider the program below. Here a user has tried to define an operator .in. that returns true if a value is found in a tree and false if not. Unfortunately one of the arguments to LISTMEMBER is a pointer. This is rejected by the compiler because according to the standard, section 12.3.2.1.1 [169:17-18], the dummy arguments must have intent IN but pointers must not have this intent, section 5.2.1 [49:3]. It appears then that an operator with pointer operands is not allowed in Fortran-90. MODULE LIST TYPE NODE INTEGER VALUE TYPE (NODE), POINTER :: NEXT END TYPE NODE INTERFACE OPERATOR (.IN.) ! check for membership in tree MODULE PROCEDURE LISTMEMBER END INTERFACE CONTAINS ! -------------------- IS A MEMBER ? -------------------- FUNCTION LISTMEMBER(VALUE,ROOTNODE) ! If ROOTNODE is given INTENT (in) then the compiler complains that ! intent may not be given to a variable with the POINTER attribute. ! If INTENT(IN) is not ! given then the compiler complains that the dummy argument rootnode must ! have an intent (when compiling the interface definition for .IN. above). TYPE (NODE), POINTER :: ROOTNODE TYPE (NODE), POINTER :: N INTEGER, INTENT(IN) :: VALUE LOGICAL LISTMEMBER LISTMEMBER = .FALSE. N => ROOTNODE DO WHILE(ASSOCIATED(N)) IF( N%VALUE == VALUE ) THEN LISTMEMBER = .TRUE. EXIT ELSE N => N%NEXT END IF END DO END FUNCTION LISTMEMBER END MODULE LIST ANSWER: Fortran 90 does not allow defined operators with pointer operands. Dummy arguments to a defined operator must have the INTENT(IN) attribute, but pointers are not allowed to have this attribute (5.2.1, 12.3.2.1.1). EDIT: None. SUBMITTED BY: Graham Barber HISTORY: 93-247 m127 submitted 93-315 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000152 TITLE: Processor dependent values for list and namelist directed output KEYWORDS: i/o list-directed, i/o namelist DEFECT TYPE: Interpretation STATUS: Published QUESTION: In Fortran 90, section 10.8.2 [150:36-37], it states For numeric output, reasonable processor-dependent integer values of w, d, and e, are used for each of the numeric constants output The previous paragraph in the section discusses the choice of 0PFw.d or 1PEw.dEe edit descriptors based on d1 and d2 processor dependent integers. This would seem to suggest that d1 and d2 are chosen once and then used for all output values. Namelist formatting, section 10.9.2.1 [154:35-40], has similar text. Question: are w, d, e, d1, and d2 chosen once and then used for all values or can different values be chosen for each numeric constant? For each numeric constant kind? If the answer is "once", then a tabular presentation results, as in the following example for a sequence of integers. 1 234 56 789 3 1000 If the answer is "chosen for each constant" then a more efficient, compact, presentation could result. 1 234 56 789 3 1000 ANSWER: All of the selection methods described in the question above are allowed. The processor is free to choose the values for w, d, e, d1, and d2 based on the value or kind of the value being printed. The processor is also free to choose permanent (fixed) values for w, d, e, d1, and d2. EDIT: None. SUBMITTED BY: Dick Weaver HISTORY: 93-248 m127 submitted 93-301 m127 response approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000153 TITLE: Defined Operations, dummy arguments INTENT(IN) KEYWORDS: INTENT(IN) attribute, defined operator DEFECT TYPE: Erratum STATUS: Published QUESTION: Section 12.3.2.1.1 states If OPERATOR is specified in a generic specification, all of the procedures specified in the interface block must be functions that may be referenced as defined operations ..... The dummy arguments must be nonoptional dummy data objects and must be specified with INTENT(IN) .... In section C.11.4, "Example of a Module", "OPERATOR" is specified for interface blocks that specify the following procedures: ELEMENT, SUBSET, UNION, DIFFERENCE, INTERSECTION Looking at those procedures, is the example correct? ANSWER: The INTENT(IN) attribute must be explicitly specified in an operator function for each dummy argument; the attribute is not "implied". Thus, the example is incorrect. Edits are provided to correct the example. REFERENCES: ISO/IEC 1539:1991 (E) Sections 12.3.2.1.1 and C.11.4. EDITS: 1. Section C.11.4, in function ELEMENT [286:16,17], change INTEGER X to INTEGER, INTENT(IN) :: X and change TYPE (SET) A to TYPE (SET), INTENT(IN) :: A 2. Section C.11.4, in function UNION [286:21], change TYPE (SET) A, B, UNION to TYPE (SET) UNION TYPE (SET), INTENT(IN) :: A, B 3. Section C.11.4, in function DIFFERENCE [286:37], change TYPE (SET) A, B, DIFFERENCE to TYPE (SET) DIFFERENCE TYPE (SET), INTENT(IN) :: A, B 4. Section C.11.4, in function INTERSECTION [287:2], change TYPE (SET) A, B, INTERSECTION to TYPE (SET) INTERSECTION TYPE (SET), INTENT(IN) :: A, B 5. Section C.11.4, in function SUBSET [287:6], change TYPE (SET) A, B to TYPE (SET), INTENT(IN) :: A, B SUBMITTED BY: Dick Weaver HISTORY: 93-262 m127 submitted 93-325 m127 response approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot approved with Moss/Reid edit 94-179 m129 edit as per WG5 ballot N981 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000156 TITLE: Forward references to a derived type definition KEYWORDS: pointer, derived type, forward reference DEFECT TYPE: Interpretation STATUS: Published QUESTION: Consider the following declarations involving a reference to a derived type: Case 1: A structure declaration makes reference to a derived type definition. TYPE(DEF) :: S TYPE DEF INTEGER I, J END TYPE Case 2: A derived type definition makes reference to another derived type definition. TYPE ONE TYPE(TWO) SUBSTRUCTURE END TYPE TYPE TWO INTEGER K END TYPE Case 3: A pointer is declared to be of derived type. TYPE(THING), POINTER :: FINGER TYPE THING REAL SKIN, HAND END TYPE Case 4: A pointer component is declared to be of derived type other than the derived type of which it is a component. TYPE ONE TYPE(TWO), POINTER :: LINK END TYPE TYPE TWO INTEGER I, J END TYPE Case 5: Two pointer components are declared to be of derived types other than the derived type of which they are a component and each pointer is of the other derived type, thus tightly linking the two derived types. TYPE ONE INTEGER :: INT_FIELD TYPE(TWO), POINTER :: LINK END TYPE TYPE TWO REAL :: REAL_FIELD TYPE(ONE), POINTER :: LINK END TYPE Notice that in all of these cases, the initial derived type reference is a forward reference to the derived type's definition. For example, in Case 1, the definition of DEF follows its reference in the declaration of structure S. It seems that all of these declaration forms are prohibited by the standard because they involve forward references to derived type definitions. The relevant text is: Case 1: p. 43, lines 21-23 When a data entity is specified to be of a derived type, the derived type must have been defined previously in the scoping unit or be accessible there by use or host association. Case 2: p. 33, lines 22-23 Constraint: If the POINTER attribute is not specified for a component, a in the must specify an intrinsic type or a previously defined derived type. Case 3: Same as Case 1. Case 4: p. 33, lines 24-26 If the POINTER attribute is specified for a component, a in the must specify an intrinsic type or any accessible derived type including the type being defined. Case 5: Same as Case 4. However, the use of the word "accessible" in the paragraph cited from page 33 seems to be inexact. It could be construed to (a) be a shorthand way of saying "accessible by use association or host association" so the sentence would properly read ... or any derived type accessible by use association or host association including ... or (b) mean "available anywhere in the current scoping unit" so the sentence would properly read ... or any derived type defined in the current scoping unit or accessible by use association or host association, including ... The first case would mean that none of the cited forward reference forms are standard conforming. The second case would mean that the reference to a derived type from a pointer component of a structure (and only this case) could be a forward reference to another derived type. Did the standard intend to allow a forward reference to a derived type definition in none of the above declaration forms, in some of the above forms (which ones?), or in all of the above forms? ANSWER: Of the declaration forms shown above, the standard allows a forward reference to a derived type only in forms exemplified by Case 4 and 5. Discussion: The second supposition above about the meaning of the word "accessible" in the sentence cited from page 33 is the correct one. Note that in all declaration forms shown except Case 5, the forward reference can be removed by moving the derived type definition to precede the reference to it. Case 5 demonstrates a declaration form where the two derived types are tightly linked via the two pointers. Forward referencing can not be avoided in this form. This form and the forward referencing that goes with it needs to be allowed since a number of applications use linked list forms where a "parent" node points to a "child" and each "child" node points back at the "parent" node. EDIT(S): None. SUBMITTED BY: L. R. Rolison HISTORY: 93-269 m127 submitted 94-048r2 m128 proposed response, approved uc 94-116r1 m129 X3J3 ballot approved 22-1 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000157 TITLE: LBOUND and UBOUND return values KEYWORDS: LBOUND intrinsic, UBOUND intrinsic, zero-sized dimension, return value DEFECT TYPE: Interpretation STATUS: Published QUESTION: The LBOUND intrinsic function returns the value 1 for a zero-sized dimension of an array and the UBOUND intrinsic function returns the value 0 for a zero-sized dimension of an array. X3J3 has stated a number of times in responses to public comments and in other public forums that zero-sized arrays were specifically designed into the language with all the rights and privileges of nonzero-sized arrays; that is, zero-sized arrays were not supposed to be treated like "second-class citizens". Given this informal approach and the formal way in which zero-sized arrays have been integrated into the language (see Chapters 6 and 7), it seems counter-intuitive for the LBOUND and UBOUND intrinsics to special-case zero-sized dimensions. For example, if a user declares an array as INTEGER array(10:3) the value 1 returned by LBOUND is no more meaningful than the value 10 that the user specified. In order for a program to know at run time whether or not an array or a dimension of an array has zero size, the program must still compare the lower bound to the upper bound or, better yet, use the SIZE intrinsic. Note that the same holds true for bounds that are calculated, like in ALLOCATE statements; that is, LBOUND should return the calculated value in these cases. The current descriptions of LBOUND and UBOUND seem to be incorrect with respect to zero-sized dimensions. Questions: (1) Are the descriptions of LBOUND and UBOUND, in fact, defective with respect to zero-sized dimensions (that is, should they return the lower and upper bounds as specified by the user)? (2) If the answer to the first question is No, what is the technical reason for LBOUND returning 1 and UBOUND returning 0 for a zero-sized dimension? ANSWER: (1) No. (2) There are three characteristics of each dimension of an array: the lower bound, the upper bound, and the extent. An implementation can calculate the address of an array element by maintaining the lower bound and upper bound or by maintaining the lower bound and the extent. If the standard were to require that the UBOUND intrinsic function return the declared or calculated upper bound, it would preclude implementations from maintaining dimension information via the lower bound and extent. EDIT(S): None. SUBMITTED BY: L. R. Rolison HISTORY: 93-270 m127 submitted 93-324 m127 response approved uc 000124 HELD 94-034 m128 X3J3 ballot passed 25-2 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000159 TITLE: May undefined expressions be used as arguments to INQUIRY functions KEYWORDS: inquiry functions DEFECT TYPE: Erratum STATUS: Published QUESTION: Section 13.7.2 Numeric inquiry functions contains the phrase "The value of the arguments to these functions need not be defined", and section 13.8.5 Array inquiry functions contains the similar phrase "The values of the array arguments to these functions need not be defined" One intent is to allow inquiries about the "static" properties of variables, for example: PROGRAM EXAMPL PARAMETER (N=3) REAL AA(N,N,N,N) REAL BB(SIZE(AA)) CHARACTER*(DIGITS(AA)) CC ... where the properties of BB and CC don't depend on the numerical values of AA. However, since the arguments to functions can also be expressions, may the expressions be undefined in the more traditional sense of not having a defined result value? Consider programs like: PROGRAM EXAMPL PARAMETER (N=3) REAL AA(N,N,N,N) REAL BB(SIZE(AA + 1.0)) CHARACTER*(DIGITS(AA + 1.0)) CC ... where the expression "AA + 1.0" is undefined in the normal sense of the word since AA is undefined. Must a processor accept programs where actual argument expressions (involving one or more operators or functions references, as opposed to expressions consisting of a single variable reference) would, if evaluated, use undefined variables or produce undefined results? ANSWER: No, the intent was only to include inquiries about the attributes of undefined variables in the set of allowed inquiries. Discussion: That the resulting text applies to all expressions was unintended and edits are provided to correct this. Note that 'variable name' does not permit substrings or section-subscripts. Edits are not provided for the PRESENT or ASSOCIATED inquiry functions; neither of these permit expressions as arguments. EDITS: 1. In section 13.5.4 Character Inquiry Function [184:18-19] replace the second sentence "The value of ...." with "If the argument to this function consists of a single primary (7.1.1.1) that is a variable name, that variable need not be defined." 2. In section 13.5.7 Bit Manipulation and Inquiry Procedures [185:4-5] In the paragraph beginning "An inquiry ..." replace the second sentence "The value of ...." with "If the argument to this function consists of a single primary (7.1.1.1) that is a variable name, that variable need not be defined, if a pointer it may have undefined or disassociated association status, and if allocatable it need not be allocated." 3. In section 13.7.2 Numeric Inquiry Functions [186:7-8] replace the last sentence "The value of ...." with "If the argument to these functions consists of a single primary (7.1.1.1) that is a variable name, that variable need not be defined, if a pointer it may have undefined or disassociated association status, and if allocatable it need not be allocated." 4. In section 13.8.5 Array Inquiry Functions [187:12] replace the second paragraph "The values of ..." with "If an array argument to these functions consists of a single primary (7.1.1.1) that is a variable name, that variable need not be defined." SUBMITTED BY: Dick Hendrickson HISTORY: 93-279 m127 submitted 94-017 m128 proposed response 94-206 m129 vote on response in 94-017, approved u.c. 94-221 m130 X3J3 ballot, approved 21-2; accept Martin and Shepherd edits N977 m131 edits 2 and 3 changed to incorporate edit from item 108 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000160 TITLE: Variables with the TARGET attribute in EQUIVALENCE groups KEYWORDS: TARGET attribute, EQUIVALENCE statement, optimization DEFECT TYPE: Erratum STATUS: Published QUESTION: The intent of the TARGET attribute is to aid in optimization. Section C.5.3 states: The TARGET attribute ... is defined solely for optimization purposes. It allows the processor to assume that any nonpointer object not explicitly declared as a target may be referred to only by way of its original declared name. The rule in 5.1.2.8 ensures that this is true even if the object is in a common block and the corresponding object in the same common block in another program unit has the TARGET attribute. It is also true that pointers may point only to variables with the same type and kind type parameters. However, there are no restrictions on variables with the TARGET attribute in EQUIVALENCE statements. EQUIVALENCE statements can fully or partially storage associate variables of the same or different types and kind type parameters. It appears that variables with the TARGET attribute may become associated with variables without the TARGET attribute, or with variables which have different types. Such storage association seriously inhibits the usefulness of the TARGET attribute in optimization, be it load/store optimization or parallel optimization. This problem appears to be even more severe than that of the C language's pointer aliasing problems in that C pointers can be assumed to alias only objects with matching types. Was it the intent of the committee to allow the storage association of target variables with nontarget variables and variables of different data types? ANSWER: No, this was not the intent of the standard. Discussion: The TARGET attribute was intended to specifically identify those variables which could be associated with pointers of the same type and type parameters. It was the intent to prohibit definition or reference of a nontarget variable through a pointer. An edit is provided to clarify the intent of the standard. EDIT: After the sixth constraint of section 5.5.1 add [57:17+] Constraint: An must not have the TARGET attribute. SUBMITTED BY: Jon Steidel HISTORY: 93-293 m127 submitted 94-049r1 m128 proposed response, approved 14-5 94-116r1 m129 X3J3 ballot approved 21-2 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000162 TITLE: Pointer expression "(i)" KEYWORDS: expression - pointer, pointer DEFECT TYPE: Erratum STATUS: Published QUESTION: Given the specifications INTEGER, POINTER :: I, J INTEGER :: K 1. Are the following statements equivalent? J => I J => (I) 2. Are the following statements equivalent? K = I K = (I) ANSWER: 1. No, the statements are not equivalent. Further, even assuming "I" has become pointer associated by statements not shown, the second pointer assignment is not standard conforming. 2. Yes, it is intended that the statements be equivalent; an edit is provided to clarify this intent. Discussion: 1. Data objects may have attributes, including the POINTER attribute (first paragraph of section 5). In addition, function references may "deliver a pointer result" (section 7.5.2 and 12.5.2.2). "(I)" is an expression containing a primary, "(I)", that is not a , a , or a subobject of a constant, therefore "(I)" is not a data object. As "(I)" is not a data object nor a function result, it cannot be a pointer. Section 7.5.2 defines two different semantics for pointer assignment, depending upon whether the is a pointer, so the statements are not equivalent. Section 7.5.2 states that must be a variable with the TARGET attribute, a subobject of a variable with the TARGET attribute, a variable with the POINTER attribute, or an expression delivering a pointer result. "(I)" is none of these, so the second pointer assignment is not standard conforming. 2. Section 7.1.4.1 states: "If a pointer appears as a primary in an intrinsic operation or a defined operation in which it corresponds to a nonpointer dummy argument, the associated target object is referenced." "(I)" does not involve an intrinsic operation nor a defined operation, so the exact treatment of the pointer object is not fully specified. Edits are provided to include this example in the quoted language from section 7.1.4.1. With the edits, the "I" contained in "(I)" references the target object, as does "(I)". Thus, in the assignment statement "K=I", "I" references the target of "I", as does "K=(I)", so the statements are equivalent. EDIT: 7.1.4.1: Change the first sentence of the last paragraph to: [76:18-19] "If a pointer appears as one of the following, the associated target object is referenced: (1) A primary in an intrinsic or defined operation, (2) As the of a parenthesized primary, or (3) As the only primary on the right-hand side of an intrinsic assignment statement." SUBMITTED BY: Dick Weaver HISTORY: 93-280 m127 submitted 94-198r1 m129 response approved 17-4 94-221 m130 X3J3 ballot, approved 20-3 with edits N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000163 TITLE: Pointer assignment of a disassociated pointer KEYWORDS: pointer, expression - pointer DEFECT TYPE: Erratum STATUS: Published QUESTION: Consider the following example from section 7.5.2 [92], POINTER_OBJECT => POINTER_FUNCTION (ARG_1, ARG_2) and suppose that the pointer returned by pointer_function is disassociated. What happens is described in section 7.5.2 [92:17], If the is a pointer that is disassociated, the also becomes disassociated. However, noting that, in the example, 'POINTER_FUNCTION ...' is an expression, and that it is a primary, this is not valid per 7.1.4.1 [76:20-22], If the pointer is not associated with a target it may appear as a primary only as an actual argument in a reference to a procedure whose corresponding dummy argument is declared to be a pointer. Also see section 7.1.7 [79:41-42], If the operand is a pointer, it must be associated ... Note that, per 7.1 [70:7], An expression is formed from operands, operators, and parentheses. Thus in an expression consisting of a single primary as in the example above, that primary is an operand. Question: Is a function that returns a pointer allowed to return a disassociated pointer? ANSWER: Yes, a function that returns a pointer is allowed to return a disassociated pointer. The text in section 7.1.4.1 is in error in appearing to disallow the result to be used in a pointer assignment statement; an edit is supplied to correct this. Section 7.1.7 applies to operands only in the context of evaluation of operations, so is not applicable to the target of a pointer assignment statement (or when the operand appears as an actual argument corresponding to a pointer dummy argument). EDIT: In the final sentence of section 7.1.4.1, insert before the terminating period ", or as the target in a pointer assignment statement." [76:22] SUBMITTED BY: Dick Weaver HISTORY: 93-281 m127 submitted 94-044r1 m128 proposed response, approved 10-6 94-116r1 m129 X3J3 ballot approved 21-2 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000165 TITLE: Vector subscripts in Namelist input KEYWORDS: vector subscript, i/o namelist DEFECT TYPE: Erratum STATUS: Published QUESTION: Can a namelist input record include vector subscripts? Section 10.9.1.1 indicates that if a namelist group object is an array then the input record can include a subobject of that array. ANSWER: No, vector subscripts are not allowed in a namelist input record. An edit to clarify this is included. Discussion: One commentor on a letter ballot noted that section 10.9.1.1 [152:8-9] states: "Subscripts, strides, and substring range expressions used to qualify group object names must be optionally signed integer literal constants". The commentor then concluded that since a vector subscript is not a literal constant, it is not allowed. Unfortunately, a vector subscript is not a , so additional edits are required. EDIT(S): In section 10.9.1, second paragraph [152:4], add the following sentence at the end of the paragraph: 'The optional qualification, if any, must not contain a vector subscript.' SUBMITTED BY: Janice C. Shepherd HISTORY: 93-285 m127 submitted 93-311r1 m127 response approved uc 94-034 m128 X3J3 ballot failed 18-10 94-015 m128 proposed changing meaning of 'subscript' in f95 94-195r1 m129 added discussion and revised edit, approved u.c. 94-221 m130 X3J3 ballot approved uc N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000166 TITLE: Array named constant is a constant expression? KEYWORDS: array constant DEFECT TYPE: Erratum STATUS: Published QUESTION: Section 6.2.1 states [63:30-31]: A whole array named constant is the name of a constant expression (5.1.2.1 and 5.2.10) that is an array. Section 5.1.2.1 [44:6] has the example INTEGER, DIMENSION(3), PARAMETER :: ORDER = (/ 1, 2, 3 /) The array constructor is a constant expression, section 4.5 [38:15-16], but why is ORDER a constant expression (as opposed to just 'constant')? Consider the following 1 INTEGER, DIMENSION(3), PARAMETER :: ORDER = (/ 1, 2, 3 /) 2 INTEGER, DIMENSION(3), PARAMETER :: CHAOS = ORDER 3 INTEGER, DIMENSION(3), PARAMETER :: KAOS = (ORDER) If ORDER is the name of a constant expression, as section 6.2.1 [63] states, then -- ORDER is not a constant expression per 7.1.6.1 as it doesn't meet any of (1) through (7) -- (ORDER) is a constant expression per 7.1.6.1, meeting (7) "a constant expression enclosed in parentheses" -- neither ORDER nor (ORDER) are initialization expressions as neither meets 7.1.6.1 requirements for initialization expressions (1) through (7) and thus statements 2 and 3, above, are both invalid. ANSWER: Expressions do not have names; an edit is provided to correct this. EDIT: Section 6.2.1, second paragraph: change "the name of a constant expression (5.1.2.1 and 5.2.10)" to "a named constant (5.1.2.1 and 5.2.10)" [63:30-31] SUBMITTED BY: Dick Weaver HISTORY: 93-282 m127 submitted 94-105r1 m128 proposed response, approved uc 94-116r1 m129 X3J3 ballot approved 22-1 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000169 TITLE: End of Namelist Input KEYWORDS: i/o namelist DEFECT TYPE: Erratum STATUS: Published QUESTION: What are the values of I and A(2) after the READ statements are executed in the following? NAMELIST /NNN/ I, J INTEGER :: A(2) = 1 READ (*,NML=NNN) or NAMELIST /QQQ/ A PRINT *, I READ (*,NML=QQQ) END PRINT *,A(2); END if the input file is: &NNN I=1, J=2, &QQQ A(1)=2, I=3/ A(2)=3/ The following set of quotes from the standard implies that the value of both I and A(2) is 1, which at least is surprising and possibly not intended. Section 9.4.6 [128:22-29]: "Termination of an input/output data transfer statement occurs when any of the following conditions are met: . . . (3) Name... input reaches the end of a record after having processed a name-value subsequence for every item in the ." In the example above, after reading I=1 and J=2, condition (3) appears to be satisfied and when the end of the record (line) is reached, the I/O should terminate. A possible reaction to this is that "record" should mean everything up to and including the "/", but a) that is NOT the definition of record generally given, and b) in section 10.9.1 [152:1], item (5) it states that "A slash to terminate the namelist input statement." This is very peculiar use of the term "statement", which does not correspond to the usage elsewhere in the standard, but it must be assume that this word was used deliberately because the word "record" is not correct (being a "line"). The other thing to consider is the position of the file after completion of the READ statement. The standard states (last sentence of 9.2.1.3.3) it should be at the end of the current record, which means that if you do another READ, you would read the line "I=3/". A slight bit of evidence that all this was not intended appears in the sentence in section 10.9.1.2 [152:47-48]. "Successive namelist records are read by namelist input until a slash is encountered; ..." (10.9.1.2 Namelist Input values) or perhaps this sentence is missing the exception listed in section 9.4.6 "Termination of data transfer statements" [128:22-29]. ANSWER: After the READ statements are executed the value of I is 3 (in the program on the left) and the value of A(2) is 3 (in the program on the right). The intent of the standard was that namelist input should proceed until it reaches the terminal "/" as indicated by item 6 in section 9.4.6, unless items 4 or 5 apply. Corrections to the standard are provided. Discussion: The sentence in section 9.4.6 item 3 [128:27-28] is wrong. For namelist input, the input data transfer statement is terminated when the terminating "/" is encountered, as discussed by item 6 in the same section. EDIT(S): 1. In section 9.4.6, item 3 [128:27-29] delete "or namelist input reaches the end of a record after having processed a name-value subsequence for every item in the " 2. In 10.9.1, item (5) [152:1], delete "statement". SUBMITTED BY: Janice C. Shepherd (for Walt Brainerd) HISTORY: 93-284 m127 submitted 93-313 m127 response approved uc 94-034 m128 X3J3 ballot failed 26-1 94-203 m129 clarified answer, approved 19-1 94-221 m130 X3J3 ballot approved 22-1 with edits N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000170 TITLE: Argument Keywords and Intrinsic Procedures KEYWORDS: argument keyword, intrinsic procedure DEFECT TYPE: Erratum STATUS: Published QUESTION: Section 14.1.2.6 'Argument Keywords' makes no mention of argument keywords associated with intrinsic procedures. Should it not include text such as the following? "A dummy argument name in an intrinsic procedure has a scope as an argument keyword of the scoping unit making reference to it." ANSWER: Yes. An edit is supplied. EDIT(S): In section 14.1.2.6 add a new paragraph after the current paragraph. [245:14+] "A dummy argument name in an intrinsic procedure has a scope as an argument keyword of the scoping unit making reference to it. As an argument keyword, it may appear only in a procedure reference for the procedure of which it is a dummy argument." SUBMITTED BY: Hideo Wada, IPSJ/ITSCJ SC22/Fortran HISTORY: 93-288 m127 submitted (Shepherd) 93-309r1 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000172 TITLE: Length specified for a character-valued statement function KEYWORDS: statement function, constant expression DEFECT TYPE: Erratum STATUS: Published QUESTION: In 5.1.1.5 [43:6-7] should The length specified for a character-valued statement function or statement function dummy argument of type character must be an integer constant expression. be changed to The length specified for a character-valued statement function or statement function dummy argument of type character must be a constant specification expression. ANSWER: Yes. Discussion: This text is based on FORTRAN 77 in 15.4.3 [15-6:40] The length specification of a character statement function or statement function dummy argument of type character must be an integer constant expression. In FORTRAN 77, integer constant expression, 6.1.3 and 6.1.3.1, did not allow function references while in Fortran 90 integer constant expression, 7.1.6.1, has a different definition and allows all elemental intrinsic functions and all transformational intrinsic functions [77:22-23]. Most such occurrences of integer constant expression in FORTRAN 77 were changed to specification expression in Fortran 90. This particular case was missed, resulting in an unusually broad extension of FORTRAN 77, and an inconsistency with the Fortran 90 syntax for character length specification R508 char-length is (type-parm-value) or scalar-int-literal-constant R509 type-parm-value is specification-expr or * An edit is provided to make the correction. EDIT: In 5.1.1.5 [43:6-7] change the paragraph following item (3) to: The length specified for a character-valued statement function or statement function dummy argument of type character must be a constant specification expression. SUBMITTED BY: Dick Weaver HISTORY: 94-090r1 m128 submitted 94-090r1 m128 proposed response, approved uc 94-116r1 m129 X3J3 ballot approved 23-0 N984 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000174 TITLE: Consistent definition of NCOPIES KEYWORDS: REPEAT intrinsic, SPREAD intrinsic, NCOPIES DEFECT TYPE: Interpretation STATUS: Published QUESTION: Consider the following two function references: REPEAT (... NCOPIES=N) SPREAD (... NCOPIES=N) Based on the definitions of REPEAT in section 13.13.87 and SPREAD in section 13.13.101, the following observations can be made. When N has a positive value: REPEAT returns the concatenation of NCOPIES of a string SPREAD returns an array, broadcasting NCOPIES of a source along a dimension When N has the value 0: REPEAT returns a zero-length string SPREAD returns a zero-sized array But, when N has the value -1, something different happens REPEAT is invalid. For repeat NCOPIES must not be negative SPREAD returns a zero-sized array. The definition of SPREAD references NCOPIES with MAX(NCOPIES,0) Thus, while uses of NCOPIES have a consistent model for both positive and zero values, the negative (out-of-range) case has introduced what would appear to be capricious differences, one an error while the other is ignored and treated as zero, thus complicating the language and astonishing the user. Should NCOPIES have a consistent definition for negative values? ANSWER: No. Discussion: As the use of NCOPIES in SPREAD is for a subscript then the returning of a zero-sized array for negative values of NCOPIES is consistent with the treatment of negative extents in array sections. Within REPEAT, NCOPIES is not used as the subscript of an array. EDITS: None SUBMITTED BY: Dick Weaver HISTORY: 94-133 m129 submitted, response supplied failed 9-14 94-133r3 m129 revised answer and deleted edits; approved 19-1. 94-221 m130 X3J3 ballot approved u.c.; accepted O'Gara edit N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000177 TITLE: Structures in EQUIVALENCE lists KEYWORDS: derived type, EQUIVALENCE statement, SEQUENCE, pointer DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 5.5.1 "EQUIVALENCE statement" contains the following constraint [57:1-5]: "Constraint: An must not be a dummy argument, a pointer, an allocatable array, an object of a nonsequence derived type or of a sequence derived type containing a pointer at any level of component selection, an automatic object, a function name, an entry name, a result name, a name constant, a structure component, or a subobject of any of the preceding objects." It seems that each of the phrases in the constraint is intended to be an independent phrase such that one could rewrite the constraint in columnar form: Constraint: An must not be a dummy argument, a pointer, an allocatable array, an object of a nonsequence derived type or of a sequence derived type containing a pointer at any level of component selection, an automatic object, a function name, an entry name, a result name, a name constant, a structure component, or a subobject of any of the preceding objects. When written in this form it seems that the phrase "an object of a nonsequence derived type or of a sequence derived type containing a pointer at any level of component selection," is disallowing an object of nonsequence derived type that contains a pointer at any level of component selection as well as an object of sequence derived type that contains a pointer at any level of component selection. However, at least two existing Fortran 90 processors declare ANY object of a nonsequence derived type in an EQUIVALENCE list as being in error, obviously because the implementers split the above phrase into "an object of a nonsequence derived type, an object of a sequence derived type containing a pointer at any level of component selection," What is the intent of the standard? ANSWER: The intent was for the latter. If the former had been intended, the wording would have been "an object of a derived type containing a pointer at any level of component selection". This is confirmed in C.5.5, line 4 [270:9]: "Structures that appear in EQUIVALENCE statements must be sequence structures.". Note that for COMMON there is a very clear restriction in 5.5.2 [58:33]: "Constraint: If a is of a derived type, it must be a sequence type (4.4.1)". An edit is supplied to make the intention clearer. EDIT: On page 57, line 2, [57:2] change "derived type or" to "derived type, an object" SUBMITTED BY: Larry Rolison HISTORY: 94-156 m129 submitted 94-287r1 m130 response, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000178 TITLE: Specific routine with same name as generic passed as argument KEYWORDS: argument - actual, specific name, generic name DEFECT TYPE: Erratum STATUS: Published QUESTION: If a generic interface contains a specific interface with the same name as the generic, can the procedure with the specific name be passed as an actual argument? The penultimate constraint in 12.4.1 states [172:7-8]: "A must not be the name of an internal procedure or of a statement function and must not be the generic name of a procedure (12.3.2.1, 13.1)." On the other hand, 12.4.1.2 states [173:33-34]: "If the specific name is also a generic name, only the specific procedure is associated with the dummy argument." These two statements appear to conflict. ANSWER: Yes. As indicated by 12.4.1.2, a specific procedure may appear as an actual argument even if it has the same name as a generic name. Discussion: The penultimate constraint of section 12.4.1 should have restricted a generic name from appearing as an actual argument when the generic name is not also a specific name. The constraint should not have restricted the appearance as an actual argument of a specific name that is also a generic name. As indicated by the referenced text from section 12.4.1.2, the latter case is permitted by the standard. An edit is provided to correct the constraint. The following program fragment is standard conforming SUBROUTINE TEST INTERFACE F FUNCTION F(X) REAL F, X END FUNCTION F END INTERFACE CALL THING (F) ! F is specific as well as generic END SUBROUTINE TEST REFERENCES: JOR item 50 EDIT: Section 12.4.1, insert the following in the penultimate constraint, ahead of "(12.3.2.1, 13.1)" [172:8]: "unless it is also a specific name" SUBMITTED BY: Janice C. Shepherd HISTORY: 94-157 m129 submitted with proposed response, approved u.c. 94-221 m130 X3J3 ballot, approved u.c. N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000181 TITLE: in STOP and PAUSE statements KEYWORDS: STOP, PAUSE DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Was it an oversight to allow named character constants in addition to character literals as the (R843) of STOP (section 8.4) and PAUSE (section 8.5) statements? ANSWER: No. It was intended that the be expanded from the forms allowed in FORTRAN 77. EDITS: None. SUBMITTED BY: Linda O'Gara HISTORY: 94-251 m130 submitted with suggested answer 94-271 m130 alternate answer proposed, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000182 TITLE: Intrinsics in statement functions KEYWORDS: statement function, interface - explicit DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Item 52 contains an edit to section 12.5.4 to add the following after the first sentence of the first constraint: [182:4] "If contains a reference to a function or a function dummy procedure, the reference must not require an explicit interface, the function must not require an explicit interface or be a transformational intrinsic, and the result must be scalar. If an argument to a function or a function dummy procedure is array valued, it must be an array name." This new text appears to disallow statement functions that were valid in FORTRAN 77. Consider the following code fragment which references the intrinsic INT. PROGRAM SF ISF(A) = INT(A) ... WRITE(6,*) ISF(2.3) END In Fortran 90 INT has an optional argument and thus must have an explicit interface (which it does have as it is an intrinsic and all intrinsics have explicit interfaces). The edited constraint, which indicates "the function must not require an explicit interface", means that this is a not a valid Fortran 90 statement function. Should the statement function shown be a valid Fortran 90 statement function? ANSWER: Yes. The statement function in the code fragment is a valid Fortran 90 statement function. Discussion: The edit in item 52 was included with the intent of limiting the definition of statement functions to mostly that which was provided by FORTRAN 77. By indicating that a function referenced in a statement function must not require an explicit interface, the intent was to prohibit the use of such functions as ones that have dummy arguments that are pointers or results that are pointers. Such functions did not exist in FORTRAN 77. It was not the intent to prohibit statement functions that were valid in FORTRAN 77. An edit is provided that corrects the edit from item 52. EDITS: Section 12.5.4. first constraint, in the second sentence, as supplied in corrigendum 1 [182:4] change "the function must not require an explicit interface or be a transformational intrinsic," to "the function must not require an explicit interface unless it is an intrinsic, the function must not be a transformational intrinsic," SUBMITTED BY: Janice C. Shepherd HISTORY: 94-263r1 m130 submitted with suggested answer, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot approved, with Reid edit --------------------------------------------------------------------------------