From janshep@watson.ibm.com Fri Jan 19 10:20:41 1996 Received: from convex.convex.com by mozart.convex.com (8.6.4/1.28) id KAA27249; Fri, 19 Jan 1996 10:20:36 -0600 Received: from watson.ibm.com by convex.convex.com (8.6.4.2/1.35) id KAA26959; Fri, 19 Jan 1996 10:26:09 -0600 Message-Id: <199601191626.KAA26959@convex.convex.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6043; Fri, 19 Jan 96 11:25:12 EST Date: Fri, 19 Jan 96 11:25:11 EST From: "Janice C. Shepherd" To: lrr@cray.com, bleikamp@convex.convex.com, whitlock@tle.enet.dec.com, gra@epcfta.edinburgh.ac.uk Status: OR PC File: 96-006b.040 Archive: 96-006.B040 -------------------------------------------------------------------------------- NUMBER: 000040 TITLE: Allocation of arrays of pointers KEYWORDS: array of pointers, pointer allocation, structure DEFECT TYPE: Interpretation STATUS: Published QUESTION: Consider the following code fragment: TYPE DEF INTEGER I INTEGER, POINTER :: PTR END TYPE TYPE (DEF) :: STRUCT (5) ... ALLOCATE (STRUCT%PTR) Are the following quotations from the standard sufficient to declare this code fragment to be nonstandard-conforming? The constraint immediately following R628 "Each must be a pointer or an allocatable array." The second sentence of the fourth constraint after R613 "A to the right of a with nonzero rank must not have the POINTER attribute." ANSWER: The ALLOCATE statement in the example is not permitted by the syntax rules and constraints of the standard: R625 is or R614 is R612 is [%]... R613 is [()] Constraint: A to the right of a with nonzero rank must not have the POINTER attribute. REFERENCES: ISO/IEC 1539:1991 (E) sections 6.1.2 and 6.3.1 EDITS: None. SUBMITTED BY: Larry Rolison, X3J3/92-056 HISTORY: Approved as X3J3/92-069 at meeting 121 92-267r m123 Edit approved N881 WG5 approval ------------------------------------------------------------------------------- NUMBER: 000041 TITLE: Procedure with target dummy argument requires explicit interface KEYWORDS: argument - dummy, interface - explicit, TARGET attribute DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: If a procedure has a dummy argument that has the TARGET attribute, it must have an explicit interface (section 12.3.1.1). The TARGET attribute is defined solely for the purpose of aiding optimization (C.5.3). Why must such a procedure have an explicit interface? ANSWER: Section C.5.3 is in error by stating the TARGET attribute is solely to aid optimization. The supplied edit corrects the error. Discussion: Defect item 000125 supplies edits to make it clear that: If the dummy argument has the TARGET attribute and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure. (2) When execution of the procedure completes, any pointers associated with the dummy argument remain associated with the actual argument. In this case, the simple argument association mechanism that involves supplying only the location of the first storage unit of the argument or of a copy of the argument (see C.12.5) is not adequate at the point of reference. In particular, the location of the actual argument and details of its layout in storage may need to be available within the called routine to ensure that the pointer association works as described. EDIT: Section C.5.3, second sentence, change "solely" to "primarily". [269:21] SUBMITTED BY: K. Kazumura, X3J3/92-048 (121-ADT-8) page 23 HISTORY: Posted request to f90 interp e-mail ui 82, ui 111, ballot, 92-329 (jw note) 92-070 m121 Approved m123 Approval rescinded (uc) 93-101 m124 Revised response adopted by uc 93-111 m125 ballot approved m128 Status changed to "consideration in progress" as this refers to edits in 000121 that no longer exist 94-235 m130 draft revision, approved uc 94-306 m131 X3J3 ballot approved 18-1 95-044 m132 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000042 TITLE: KIND parameter value KEYWORDS: kind type parameter, constant DEFECT TYPE: Interpretation STATUS: Published QUESTION: It is stated in section 5.1.1.2 that: An entity declared with type specifier REAL(KIND(0.0)) is of the same kind as one declared with the type specifier REAL. There are similar statements about INTEGER, DOUBLE PRECISION, and COMPLEX type specifiers in sections 5.1.1.1, 5.1.1.3, and 5.1.1.4. In section 5.1.1.2, for example, must the constant be exactly the characters "0.0" to cause the declared entity to be the same as the default real entity? Could the result be different if the constant were expressed, for example, as "0."? It appears that the committee chose the value 0 in these statements because it exists on every machine on which a Fortran 90 processor will be run. Further, a specific value was chosen so that machine architecture differences would be factored out. For example, KIND(10000000.) might have the same kind parameter value as default real on one machine but not on another. ANSWER: No, the constant need not be exactly "0.0". The constant "0.0" is used only as an example. Discussion: The KIND intrinsic is defined in section 13.13.51 of the standard to return a value equal to the kind type parameter of its argument; the argument may be of any intrinsic type. In section 13.5.5 it is stated that the value of the argument to this function need not be defined. It is only the kind type of the argument that is relevant. Nowhere in the standard is there a restriction that the argument to the KIND intrinsic be a constant at all, much less the specific constant 0.0. The is specified in section 5.1, R505 to be a . The definition of an is given in section 7.1.6.1, and the restrictions on the argument of the KIND intrinsic in an are detailed in item (6) of that definition. The question makes the assertion that KIND(10000000.) might not have the same kind parameter value as default real on all machines. This assertion is false. Possibly the requestor believed that a literal real constant could assume a kind parameter value based on the number of digits in the constant or some other implicit criterion. This is not allowed in Fortran 90. In section 4.3.1.2, it is explicitly stated that: A literal real constant without a kind type parameter is a default real constant if it is without an exponent part..." Similar arguments apply to the corresponding questions about INTEGER, DOUBLE PRECISION, and COMPLEX type specifiers. REFERENCES: ISO/IEC 1539:1991, sections 4.3.1.2, 5.1, 5.1.1, 7.1.6.1, 13.5.5, 13.13.51 EDITS: None. SUBMITTED BY: Larry Rolison, X3J3/92-060 HISTORY: Approved as X3J3/92-084 at meeting 121 by a vote of 19-0 92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000043 TITLE: List-directed character input KEYWORDS: i/o list-directed, character, zero length DEFECT TYPE: Erratum STATUS: Published QUESTION: For list directed input of character items, how does the standard distinguish between the input of an undelimited zero-length character string and a null value? If the input is a zero-length character string, the corresponding list item must be set to blank, whereas if the input is a null value, the definition status of the corresponding list item must be left unchanged. However, there appears to be no way to distinguish these two possibilities. ANSWER: The ambiguity between undelimited zero length character values and the null value should be resolved by requiring that zero-length character values always be delimited in list-directed input. Discussion: Several other potential ambiguities with undelimited character items in list-directed input were resolved in section 10.8.1 by requiring delimiters in those cases. However, the case of a zero-length string was omitted from this list. EDITS: 1. Section 10.8.1: Add " and" to the end of item (4), and [149:12] 2. Section 10.8.1: Add an additional item to the list after item (4): [149:12] "(5) The character constant contains at least one character," SUBMITTED BY: Richard E. Maine, X3J3/92-087 HISTORY: X3J3/92-116 m121 Approved by a vote of 19-0 Approved in ballot 92-182 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000044 TITLE: END statement and fixed form source KEYWORDS: END statement, source form - fixed - initial line DEFECT TYPE: Erratum STATUS: Published QUESTION: Consider the following: 1. Section 3.3.2.4 "Fixed Form Statements", page 24, requires that no statement, except the program unit END statement, have an initial line that appears to be a program unit END statement. 2. Other statements, for example, , R1218 page 175, may consist of only the keywords "END" or "END FUNCTION". While these do not conflict, the combined requirements are not obvious and complicate the situation for users. Consider, for example, ending an for a function subprogram: 1. END ! wrong, appears to be a program unit END 2. EN ! END continued to 2nd line. OK & D 3. END FUNCTION ! OK in main PROGRAM unit and SUBROUTINE ! subprogram, wrong in FUNCTION subprogram 4. EN ! OK & D FUNCTION 5. END F ! OK 6. END FUNCTION A ! OK in main program, OK in SUBROUTINE & BC !subprogram, OK in function if name is not "A" ANSWER: Section 3.3.2.4 was brought forward from FORTRAN 77 without modification for new Fortran 90 constructs. The resulting usability characteristics, as seen in the examples above, are regrettable enough that a repair should be made. EDIT: In 3.3.2.4 replace the text "and no other statement in the program unit may have an initial line that appears to be a program unit END statement" with ". A statement whose initial line appears to be a program unit END statement must not be continued." [24:13] SUBMITTED BY: Janice C. Shepherd, X3J3/92-012, X3J3/92-013, X3J3/92-014 HISTORY: Approved as X3J3/92-088A at meeting 122 by a vote of 24-0 92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000045 TITLE: Array intrinsics with arrays of derived-type arguments KEYWORDS: array intrinsics, derived type DEFECT TYPE: Interpretation STATUS: Published QUESTION: The intrinsic functions ALLOCATED, ASSOCIATED, LBOUND, UBOUND, PRESENT, SHAPE, SIZE, MERGE, PACK, SPREAD, UNPACK, CSHIFT, EOSHIFT, TRANSPOSE, RESHAPE, and TRANSFER are documented as accepting arrays of any type. Does this include arrays of derived-type, and if so, does this conflict with section 4.4.5 which states: Any operation on derived-type entities or nonintrinsic assignment for derived-type entities must be defined explicitly by a function or subroutine and a procedure interface block. ANSWER: The intrinsics in question can accept arguments which are arrays of derived-types. This does not conflict with section 4.4.5. Discussion: The term "operation" in section 4.4.5 refers to user defined unary and binary operations in expressions and nonintrinsic assignments. Such operators are defined by means of interface blocks which define operators and nonintrinsic assignment. Using an object as an actual argument in a procedure reference is not considered an operation on that object in this sense. REFERENCES: ISO/IEC 1539:1991 section 4.4.5 and 13.13 X3J3/92-051 pages 13-14 EDITS: None. SUBMITTED BY: H.Funaki, X3J3/92-051 (121-ADT-11) pp13-14 HISTORY: Posted request to f90 interp e-mail Approved as X3J3/92-092A meeting 121 by a vote of 19-0 92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000046 TITLE: RESULT clause for RECURSIVE functions KEYWORDS: function result, recursive function DEFECT TYPE: Interpretation STATUS: Published QUESTION: 1. Does RECURSIVE require RESULT? 2. Assuming (1), is a permitted on the function name when RECURSIVE is present? ANSWER: The RESULT clause is not required for all RECURSIVE functions; it is required for those that are directly recursive. That is, the RESULT clause is necessary to make the function visible in its own body so that direct recursion can take place. It should be noted that the prohibition against typing the function name when a result variable name is specified was not intended to prohibit putting the function type into the header. In other words: FUNCTION F() RESULT (FVAR) INTEGER FVAR and INTEGER FUNCTION F() RESULT (FVAR) are both allowed. The case prohibited is: FUNCTION F() RESULT (FVAR) INTEGER F It is possible for both a and RECURSIVE to appear in a single function header. REFERENCES: ISO/IEC 1539:1991 (E) section 12.5.2.2 EDITS: None. SUBMITTED BY: L.Meissner, X3J3/92-045 (121-ADT-5) p17. HISTORY: For discussion see X3J3/92-45 (121-ADT-5) pp 18, 26-27 Approved as X3J3/92-101 at meeting 121 by a vote of 20-0 92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000047 TITLE: Automatic data object in initialization expressions KEYWORDS: automatic, expression - initialization, PARAMETER statement DEFECT TYPE: Erratum STATUS: Published QUESTION: Can an automatic data object be used as the argument to the LEN function in the initialization expression of a PARAMETER statement or an item given the PARAMETER attribute? ANSWER: No. It was the intent of the committee to include objects with nonconstant lengths in the restrictions on the LEN function in section 7.1.6.1 (pages 77 and 78). EDITS: 1. Section 7.1.6.1, page 77, item (6) change "not assumed or" to "not assumed, are not defined by an expression that is not a constant expression, and are not" [77:27] 2. Section 7.1.6.1, page 78, item (6) change "not assumed or" to "not assumed, are not defined by an expression that is not an initialization expression, and are not" [78:9] SUBMITTED BY: 120.042 LAST SIGNIFICANT CHANGE: 93-07-16 000047 m126 changed "constant" to "initial..." HISTORY: X3J3/92-036 (121-JKR-4) and 120.073A For discussion X3J3/92-107 m121 approved by a vote of 20-0 X3J3/92-267r m123 edit approved N881 WG5 approval X3J3/93-151 m125 approved unanimous consent N903 changed 1st edit "a constant" to "an initialization" to match -------------------------------------------------------------------------------- NUMBER: 000048 TITLE: Pointer-valued statement functions KEYWORDS: statement function, pointer DEFECT TYPE: Interpretation STATUS: Published QUESTION: Can a statement function be pointer-valued? There appears to be nothing in section 12.5.4 to prohibit this. ANSWER: No, a statement function cannot be pointer-valued. Discussion: From section 12.3.1: The interface of a statement function is always implicit. >From section 12.3.1.1: A procedure must have an explicit interface if... (2) The procedure has: (e) A result that is a pointer (functions only) Therefore, a statement function cannot have a result that is a pointer. EDITS: None. SUBMITTED BY: L.Meissner, X3J3/92-45 (121-ADT-5) p37 HISTORY: Approved as X3J3/92-108 at meeting 121 by a vote of 19-0 92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000050 TITLE: Repeat counts on edit descriptors KEYWORDS: i/o edit descriptor, i/o repeat count in format-directed DEFECT TYPE: Interpretation STATUS: Published QUESTION: Is the repeat specification part of the edit descriptor? In section 10.1.1 the second constraint states that the comma separating the in a is optional between certain combinations of edit descriptors. In section 10.2 a format-item is defined as, amongst other things, "[r]" and in 10.2.1 an edit-descriptor can be a data-edit-desc. However, does not contain the repeat count. This implies that: 100 FORMAT(1PE20.10) ! is legal 200 FORMAT(1P3E20.10) ! is not legal 300 FORMAT(1P,3E20.10) ! is legal ANSWER: The repeat count is not part of any edit descriptor except the "[r]/" edit descriptor. The comments in the examples are correct. Discussion: This problem appears to stem from an incompatibility between FORTRAN 66 and FORTRAN 77. In FORTRAN 66 a FORMAT statement is of the form: FORMAT(list) where the list consists of a series of field descriptors separated by field separators and optionally preceded and succeeded by slashes. The field descriptors for real or double precision values consisted of the now familiar Dw.d, Ew.d, Fw.d, and Gw.d edit descriptors (a term introduced in FORTRAN 77) preceded by an optional scale factor and repeat count. For example, in FORTRAN 66 a valid field descriptor is 1P3E17.10, where 1P is the scale factor, 3 the repeat count for a field containing 10 digits in the fractional part of the number and having a E exponent. In FORTRAN 77 the scale factor is an edit descriptor and thus is a list element in the format specification. While FORTRAN 77 specifies places where the commas separating list elements in a format specification are optional, it fails to make a comma between the scale factor and an immediately succeeding repeated D, E, F, or G edit descriptor optional. This situation has been carried over to Fortran 90. Thus: 100 FORMAT(1PE20.10) ! is legal in F66, F77, and F90 200 FORMAT(1P3E20.10) ! is legal in F66, and illegal in F77 & F90 300 FORMAT(1P,3E20.10) ! is illegal in F66, and legal in F77 & F90 EDITS: None. SUBMITTED BY: A.D. Tait, X3J3/92-041 (121-ADT-1) HISTORY: X3J3/92-041 X3J3/92-042 X3J3/92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000051 TITLE: On unambiguous generic procedure references KEYWORDS: generic procedure DEFECT TYPE: Interpretation STATUS: Published QUESTION: Should the rules in 14.1.2.3 include a rule that uses the fact that a dummy argument is either a subroutine or a function to disambiguate a generic procedure reference? For example, such a rule could be in section 14.1.2.3, in the sentence that is preceded by "(1)", after "with a different type" adding "present as a subroutine instead of a function". ANSWER: No. The intent of the committee was to keep the rules as simple as possible in order that they would be easy to understand and to use. It is not always possible for the processor to tell whether an actual argument that is a procedure is a subroutine or an implicitly typed function. EDITS: None. SUBMITTED BY: John Reid, SC22/WG5 N786A HISTORY: 266 (jw note) X3J3/92-017 m121 generic interfaces and dummy procedure arguments X3J3/92-151 m122 Approved 25-0 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000052 TITLE: Expressions in statement function definitions KEYWORDS: statement function DEFECT TYPE: Erratum STATUS: Published QUESTION: Section 12.5.4 appears to prohibit whole array names appearing as actual arguments to functions within the of a statement function. The first constraint states: The may be composed only of constants (literal and named), references to scalar variables and array elements, references to functions and function dummy procedures, and intrinsic operators. A defined operator may be an extended intrinsic operator, as well as a defined unary or binary operator. Question 1: Is the legal FORTRAN 77 program fragment, EXTERNAL FCN REAL A(2) STFN(X) = FCN(A) + X where FCN is some function and STFN is a statement function, a legal Fortran 90 program fragment? Question 2: Is it intended that a defined operator which is an extended intrinsic operator be allowed in a statement function definition but other defined operators not be allowed? ANSWER: The intent is that the program fragment in question one should be a valid Fortran 90 program fragment, and that no defined operators be allowed in a statement function definition. The standard is in error. The edits below should be applied to correct the standard. Discussion: The intent of the standard was to retain the FORTRAN 77 definition of statement functions without extending it to include defined operators or array expressions. In FORTRAN 77, "expression" and "variable" referred only to scalar expressions and variables; there were no defined operators. In Fortran 90 these terms also refer to array expressions and arrays. The Fortran 90 definition of statement functions was intended to prohibit array expressions but overlooked the use of an array name as an actual argument to a function in the definition of a statement function. EDITS: 1. Section 12.5.4: First constraint, first sentence [182:4] change "references to scalar variables and array elements" to "references to variables" change "intrinsic operators" to "intrinsic operations" after first sentence add 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. 2. Section 12.5.4: Second constraint, third sentence [182:12] change "scalar variable, array element" to "variable" 3. Section 12.5.4: Fifth constraint, first sentence delete second word ("scalar") [182:19] SUBMITTED BY: A.D. Tait X3J3/92-064 item # 13 points to B. Smith e-mail in X3J3/92-045 pp. 50-52 HISTORY: X3J3/92-153A m122 Approved 17-2 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000053 TITLE: Optional intrinsic function arguments KEYWORDS: intrinsic function, argument - optional DEFECT TYPE: Amendment STATUS: Published QUESTION: Should constraining text be added to the description of optional argument Y in CMPLX, and optional argument BACK in INDEX, and optional argument SIZE in ISHFTC, and optional argument A3,... in MAX, and optional argument A3,... in MIN, and optional argument BACK in SCAN, and optional argument BACK in VERIFY to state that the argument must not be an optional argument of an invoking procedure? ANSWER: In principle yes; however it is more appropriate to add an additional restriction on dummy arguments not present in section 12.5.2.8. Discussion: The standard contains numerous restrictions intended to ensure that the rank of a given expression never changes. The case of elemental functions with optional arguments was inadvertently overlooked. Consider the following subprogram: SUBROUTINE SUB (A,B,C) INTEGER :: A ,B INTEGER, OPTIONAL :: C (:) PRINT *, MAX (A, B, C) END When C is present, the result of the elemental function MAX, is an array of the same shape as C. However, if SUB were to be called with the third argument omitted, the result would be a scalar. The supplied edit remedies this deficiency. REFERENCES: ISO/IEC 1539:1991 (E) 12.5.2.8, 13.13.20, 13.13.46, 13.13.50, 13.13.52, 13.13.63, 13.13.68, 13.13.91, 13.13.111, 13.13.113. EDITS: 1. Add the following point to the numbered list in section 12.5.2.8: [179:38] (5) If it is an array, it must not be supplied as an actual argument to an elemental procedure unless an array of the same rank is supplied as an actual argument corresponding to a nonoptional dummy argument of that elemental procedure. 2. In the paragraph following the numbered list, replace "It" with "Except as noted in (5) above, it" [179:39] SUBMITTED BY: response to X3J3/92-058 (121-LRR-5) HISTORY: X3J3/92-058 Submitted as question, draft response prepared N786A John Reid's paper N815A of the WG5 Victoria meeting X3J3/92-094 X3J3/92-156r m122 approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000054 TITLE: Resolving generic procedure references KEYWORDS: generic name, interface block, intrinsic procedure DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Consider the following code fragment: PROGRAM HOST DIMENSION ABS(10) ... CONTAINS SUBROUTINE SUB() INTERFACE ABS FUNCTION IA1(I) INTEGER IA1, I END FUNCTION END INTERFACE R = ABS(1.5) Do the rules for resolving references to names established to be generic (14.1.2.4.1) imply that R will be assigned the value 1.5 as the result of invoking the intrinsic ABS? ANSWER: Yes. Discussion: ABS is established to be generic in the scope of subroutine SUB (14.1.2.4 item 1(a)). The rules in section 14.1.2.4.1 can be used to resolve the procedure reference. Rule (1) in 14.1.2.4.1 does not apply, as the reference is not consistent with any specific interface in the interface block with the name ABS. Rule (2) does not apply as ABS does not appear in an INTRINSIC statement. Rule (3) does not apply as ABS is not established to be generic in the host scope. Therefore, rule (4) is applied and the reference is resolved to the generic intrinsic procedure ABS. EDITS: None. SUBMITTED BY: Janice C. Shepherd HISTORY: 92-048 pg 29-30, 34-40, 51, 52, One of the questions raised in 92-052 pg 1-3 One of the questions raised in 92-119 Initially drafted 92-157 m122 approved m129 WG5 #550 email, J Martin, 94-04-26, failed WG5 ballot 94-293 m130 change status to HOLD for 000083 HOLD for 83 95-281 m135 WG5 ballot approved; (83 was also WG5 ballot approved) -------------------------------------------------------------------------------- NUMBER: 000055 TITLE: Characteristics of character function results KEYWORDS: character function, function result DEFECT TYPE: Erratum STATUS: Published QUESTION: In section 12.5.2.5 the second paragraph after the constraints contains the text: "Otherwise, they are storage associated and must all be scalars without the POINTER attribute and all be of type default character with identical length". Is some of this text redundant? ANSWER: Yes. Discussion: The phrase referring to "identical length" was meant to include the FORTRAN 77 character storage association case. FORTRAN 77 requires either that they all be of assumed length or all be of the same constant length; both are included as characteristics that agree in section 12.5.2.5 in the second paragraph after the constraints that starts with "If the ENTRY". The phrase is redundant and is causing confusion. EDIT: In Section 12.5.2.5 in the sentence that starts: "Otherwise, they ... " delete: "all be scalars ... length or". [178:19] SUBMITTED BY: John Reid in N786A at the WG5 Victoria Meeting, July 1992. HISTORY: X3J3/92-158 m122 Drafted at the WG5 Victoria Meeting July, approved N881 WG5 approval ------------------------------------------------------------------------------- NUMBER: 000056 TITLE: TRANSFER intrinsic function description KEYWORDS: TRANSFER intrinsic DEFECT TYPE: Interpretation STATUS: Published QUESTION: Should the text of Case (iii) under Examples in the TRANSFER intrinsic function be corrected so the example reads: Case (iii): TRANSFER((/1.1,2.2,3.3/),(/ (0.0,0.0) /),1) is a complex rank-one array of length one whose sole element has the value (1.1,2.2)." ANSWER: No. Discussion: The current format of the example, 1.1+2.2i, is valid mathematical notation for complex type. EDITS: None. SUBMITTED BY: Larry Rolison in X3J3/92-059 (121-LRR-6) LAST SIGNIFICANT CHANGE: 92-11-13 000056 opposite response HISTORY: X3J3/92-059 Submitted X3J3/92-091 Draft response X3J3/92-159 m121, m122 Subsequent draft rejected X3J3/92-294 m123 Revised response, approved by uc N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000057 TITLE: Prohibition against multiple explicit specific interfaces KEYWORDS: interface DEFECT TYPE: Erratum STATUS: Published QUESTION: What is the meaning and/or intent of the following sentence in 12.3.2.1? A procedure must not have more than one explicit specific interface in a given scoping unit." Multiple SPECIFIC interfaces can not be produced by the existence of interface blocks because the definition of an interface body states that it only specifies an EXPLICIT interface, not a SPECIFIC interface. According to the statement in 12.3.2.1: "An external or module subprogram definition specifies a specific interface for the procedures defined in that subprogram", only external or module subprograms have specific interfaces and the specific interfaces are only specified by the text of the subprogram itself. Could an example of code be provided that is prohibited by the statement "a procedure must not have more than one explicit specific interface in a given scoping unit" in 12.3.2.1 and that would not be prohibited by some other provision of ISO/IEC 1539:1991? ANSWER: The statement in the question that "Multiple SPECIFIC interfaces can not be produced by the existence of interface blocks" is incorrect. An example follows. Discussion: The paragraph following the constraints, in 12.3.2.1 is concerned with "specific interfaces" and it was intended to be understood from the context in that discussion that the interface specified by an interface body should be both specific and explicit. See also 14.1.2.4, (2), (a) which shows that it was intended that an interface body define a specific interface. The intention was to disallow the same information being provided twice, as for other specifications. An edit is supplied to make this clearer. An example which illustrates what is prohibited follows: Example: MODULE MOD INTERFACE SUBROUTINE SUB(I,J) INTEGER I,J END SUBROUTINE SUBROUTINE SUB(M,N) ! duplication of SUB is illegal INTEGER M,N END SUBROUTINE END INTERFACE END MODULE EDITS: Section 12.3.2.1, the sentence that begins "An interface body..." change "explicit interface" to "explicit specific interface". [167:39] SUBMITTED BY: Larry Rolison LAST SIGNIFICANT CHANGE: 92-11-13 000057 HISTORY: 120.035, 120.090 X3J3/92-162A m122 Approved by uc 92-192, 222, 263, 314 (original) (jw note) X3J3/92-314 m123 Revised following letter ballot to correct transcription errors in the recording of what was contained in 92-162A N881 WG5 passed -------------------------------------------------------------------------------- NUMBER: 000058 TITLE: Ambiguous use of "keyword" KEYWORDS: keyword, argument keyword, statement keyword DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Is the use of "keyword" in 12.4.1, page 172, 1st paragraph consistent with the definition of "keyword" in 3.2.1, page 19? Is the definition of keyword in 3.2.1 consistent with the two definitions of keyword in 2.5.2, page 16? In 13.10, page 188, is "keyword" the correct term (or should it be "argument keyword")? ANSWER: The term "keyword" is used for both "statement keyword" and "argument keyword" - see 2.5.2 and Annex A. Which is intended is usually clear from the context, and this is so on pages 172 and 188. Section 3.2.1 is referring only to statement keywords and would be clearer if the qualifier "statement" is added. EDITS: Page 19 section 3.2.1 [19:37-38] Change "Keywords" to "Statement keywords" twice. Rationale: 3.2.1 is not referring to argument keywords. SUBMITTED BY: GEN HISTORY: WG5/N808, Question 2. 92-164A m122 approved 17-4 ballot comments, 92-326 (jw note) m124 minutes, approved 15-2 93-111 m125 ballot approved with Kelble edits 94-160 m129 WG5 ballot, failed; 94-361 m131 answer with fewer edits proposed, approved u.c. 95-034r1 m132 X3J3 ballot, approved 20-0 95-281 m135 WG5 ballot approved; -------------------------------------------------------------------------------- NUMBER: 000059 TITLE: SEQUENCE derived type and component bounds KEYWORDS: SEQUENCE, derived type DEFECT TYPE: Interpretation STATUS: Published QUESTION: Given two objects of SEQUENCE derived type, can the two objects be of the same derived type if the only difference between the two SEQUENCE derived type definitions is the value of the low bound and high bound for one dimension of one of the components (assuming the extent of the dimension of the array component matches the extent given in the other; and there are no structure components that have PRIVATE accessibility)? The description of when two objects of SEQUENCE derived type have the same type includes the words (2nd paragraph of 4.4.2 "Determination of derived types") "have structure components that do not have PRIVATE accessibility and agree in order, name, and attributes". This text seems to imply that if the derived type includes an then the individual low bounds and high bounds have to be the same. An example that corresponds to the question above: SUBROUTINE S() TYPE T SEQUENCE INTEGER A(1:10) END TYPE TYPE (T) X CALL S2(X) ... SUBROUTINE S2(Y) TYPE T SEQUENCE INTEGER A(2:11) END TYPE TYPE (T) Y ... Do X and Y have the same type? ANSWER: No. Discussion: The attributes that a data object may have are enumerated in section 5.1.2. Included in these is the DIMENSION attribute (section 5.1.2.4). In reference to the explicit shape arrays in the example above, in order for the attributes to agree, the values of the corresponding lower bounds and the corresponding upper bounds in must be equal. EDITS: None. SUBMITTED BY: Janice C. Shepherd X3J3/92-129 HISTORY: X3J3/92-129 X3J3/92-165A m122 Approved 19-2 Approved in ballot 92-182 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000060 TITLE: Statement function argument references KEYWORDS: statement function arguments DEFECT TYPE: Interpretation STATUS: Published QUESTION: Consider the following program: PROGRAM TEST INTEGER AR EXTERNAL AR REAL A(2), FUN, X, Y DATA A/2*5./ FUN(X) = X+X+X Y=FUN(A(AR(5))) END INTEGER FUNCTION AR(I) INTEGER I AR = 1 PRINT *, I RETURN END When the statement function is referenced, how many times is the function AR called? Or, to put it another way, how many times is the PRINT statement in function AR executed during the statement function reference? ANSWER: In the program above, the function AR is called once unless the value of the function "can be determined otherwise" than by evaluating the function. Therefore, the PRINT statement in function AR is executed at most once. Discussion: When the statement function is referenced, the actual arguments are evaluated and the resulting values are associated with the corresponding dummy arguments. The statement function FUN has only one actual argument which contains only one reference to the external function AR. Therefore, the function AR is called once as part of the evaluation of the actual argument. The value resulting from this evaluation is associated with the single dummy argument of the statement function FUN. Though the PRINT statement may be executed once, note that 7.1.7.1 gives license to the processor to not execute the PRINT statement at all. Thus the statement in the answer is "the PRINT statement in function AR is executed at most once". REFERENCES: ISO/IEC 1539:1991 (E) sections 7.1.7.1 and 12.5.4, the fourth paragraph after the last constraint EDITS: None. SUBMITTED BY: Linda J. O'Gara LAST SIGNIFICANT CHANGE: 92-11-13 000060 HISTORY: 121-LJO-3, 121-ADT-11 pages 14-17 X3J3/92-168 m122 Approved 17-0 X3J3/92-315 m123 Revised after letter ballot m123 Revision approved by unanimous consent N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000061 TITLE: G edit descriptor with "d" = 0 KEYWORDS: i/o G edit descriptor, i/o edit descriptors, conformance DEFECT TYPE: Erratum STATUS: Published QUESTION: Is a value of 0 for "d" in a G edit descriptor (e.g. 1PG8.0) permitted? ANSWER: Yes. See R1008, R1005, and R404. QUESTION: Did the committee mean to change the definition of G format in Fortran 90 (compared to FORTRAN 77)? ANSWER: Yes. The form of output text produced by the G edit descriptor for some values and particular edit descriptors was intentionally changed. The changes require processors to give meaningful output instead of "*"s for certain values and edit descriptors. QUESTION: What happens when N (the value to be printed) is zero and "d" is zero? ANSWER: The standard indicates a format of F(w-n).-1 is to be used. This is an error in the standard. EDITS: 1. In section 10.5.4.1.2 second paragraph, 3rd sentence, after "- 0.5," add " or N is identically 0 and d is 0,". [144:37] 2. In section 10.5.4.1.2, second paragraph, fourth sentence, after "N is identically 0" add " and d is not zero". [144:40] 3. In section 1.4.1, add item (5) as follows: [3:32] (5) A value of 0 for a list item in a formatted output statement will be formatted in a different form for some G edit descriptors. In addition, the Fortran 90 standard specifies how rounding of values will affect the output field form, but FORTRAN 77 did not address this issue: therefore, some FORTRAN 77 processors may produce a different output form than Fortran 90 processors for certain combinations of values and G edit descriptors. SUBMITTED BY: Joanne Brixius, 121-JB-1 HISTORY: 121-ADT-7 pp 1-9, 92-076, 92-118 X3J3/92-149A m122 Approved 20-3 X3J3/92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000062 TITLE: Statement function constraints KEYWORDS: statement function, host association DEFECT TYPE: Erratum STATUS: Published QUESTION: Does the last constraint under R1226 allow variables in a of a statement function definition to be accessed via host association or use association? PROGRAM HOST INTEGER I ... CONTAINS SUBROUTINE INNER() STMTFUNC()=I+1 ... ANSWER: Yes. Discussion: It was the intent of the committee to allow variables made accessible by use or host association to appear in a of a statement function definition. The text of the last constraint under R1226 needs clarification to better reflect that intent. REFERENCES: ISO/IEC 1539:1991 (E) section 12.5.4 EDITS: In the last constraint after R1226 in section 12.5.4 replace "local to" with "accessible in". [182:20] SUBMITTED BY: Janice C. Shepherd X3J3/92-015 HISTORY: X3J3/92-046 Discussed in, pp 28-29 X3J3/92-120 Initially drafted X3J3/92-160 m122 Approved 23-0 X3J3/92-182 Approved in ballot N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000063 TITLE: Interfaces and dummy procedure arguments KEYWORDS: interface - explicit, procedure - dummy DEFECT TYPE: Interpretation STATUS: Published QUESTION: Given a procedure that has a dummy argument, must an explicit interface for the procedure show sufficient information to indicate that its dummy argument is a dummy procedure? ANSWER: Yes. Discussion: The first sentence of the second paragraph in 12.3.2.1 indicates that an interface body must specify all of the procedures characteristics. Section 12.2 indicates that a procedure's characteristics include the characteristics of its arguments. Therefore, an interface body must include an EXTERNAL statement or a nested interface block for each dummy argument that is a dummy procedure, even though this may not be necessary in the procedure definition. EDITS: None. SUBMITTED BY: Janice C. Shepherd, X3J3/92-016 HISTORY: X3J3/92-161 m122 Approved 24-0 X3J3/92-182 Approved in ballot N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000064 TITLE: SPACING result for 0.0 KEYWORDS: SPACING intrinsic DEFECT TYPE: Erratum STATUS: Published QUESTION: Is the SPACING intrinsic function intended to return absolute spacing of model numbers about 0.0 when its argument is 0.0? Section 13.12.100 under Result Value specifies that the result should be b**(e-p); this is not equal to the absolute spacing of model numbers around zero because zero has e == 0, so b**(e-p) provides a much larger value than expected. ANSWER: Yes. Discussion: Since the smallest magnitude model numbers are TINY(X) and -TINY(X), the absolute spacing around zero is TINY(X). It was intended that the "otherwise" clause of the SPACING definition apply to this case. REFERENCES: ISO/IEC 1539:1991 (E) Sections 12.7.1 and 13.13.100. EDITS: In section 13.13.100, after "Result Value." change "The" to "If X is not zero, the". In the same section, change "; otherwise " to ". Otherwise". [234:6] SUBMITTED BY: John Reid HISTORY: N786a item 234/7 N815a item 6 (X3J3/92-136 item 6) X3J3/92-171 m122 Approved 22-0 X3J3/92-267r m123 Edit approved in N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000065 TITLE: DO construct - Block and Nonblock KEYWORDS: DO construct - block and nonblock DEFECT TYPE: Interpretation STATUS: Published QUESTION: Consider the following DO loop: DO 10, I = 1, 10 K = I 10 CONTINUE It can be parsed using either of the following two paths: R816 is R817 is R818 is R819 is DO