From janshep@watson.ibm.com Fri Jan 19 10:20:15 1996 Received: from convex.convex.com by mozart.convex.com (8.6.4/1.28) id KAA27216; Fri, 19 Jan 1996 10:19:38 -0600 Received: from watson.ibm.com by convex.convex.com (8.6.4.2/1.35) id KAA26939; Fri, 19 Jan 1996 10:25:13 -0600 Message-Id: <199601191625.KAA26939@convex.convex.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6033; Fri, 19 Jan 96 11:24:53 EST Date: Fri, 19 Jan 96 11:24:51 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.160 Archive: 96-006.B160 -------------------------------------------------------------------------------- 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: 000161 TITLE: Modules and private derived types KEYWORDS: module, private, derived type definition, structure component DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: In compiling a Fortran 90 program, the following issues came up: Question 1:Section 4.4.1 (page 34) states: "The accessibility of a derived type may be declared explicitly by an in its or in an (5.2.3). The accessibility is the default if it is not declared explicitly. If a type definition is private, then the type name, the structure value constructor (4.4.4) for the type, any entity that is of the type, and any procedure that has a dummy argument or function result that is of the type are accessible only within the module containing the definition." Applying this to the following code: MODULE M1 PRIVATE TYPE FRED INTEGER F1,F2 END TYPE FRED TYPE(FRED), PUBLIC, PARAMETER :: Y=FRED(1,2) TYPE(FRED), PUBLIC :: X END it can be seen that entities X and Y are accessible only within module M1. Is specifying the PUBLIC attribute for X and Y an error? Question 2:Now what about this code: MODULE M2 TYPE FRED INTEGER F1,F2 END TYPE FRED END MODULE M3 USE M2 PRIVATE TYPE(FRED), PUBLIC :: X END In module M3, the public type FRED imported from M2 becomes private. Is the declaration of X standard conforming? The text in 4.4.1 is inadequate to cover this scenario. The declaration should be illegal but it depends on what is meant by "module containing the definition" in 4.4.1. The standard appears to describe the M1 case not the M3 case. The problem appears to be that module M2 contains the definition of the public type FRED and the module M3 contains the "definition" of the private type FRED. ANSWER 1: Yes. ANSWER 2: Yes. The declaration of X in the module M3 is standard conforming. Discussion: The answer to question 2 depends on the interpretation of what it means for a module to "contain a definition" of a type. The second paragraph of section 4.4.2 states: "Two entities have the same type if they are declared with respect to the same type definition. The definition may be accessed from a module..." This wording implies that module M3 does not contain a definition of the type FRED; it accesses the definition contained in module M2. Thus, it is the accessibility of FRED in module M2 that is referred to by the cited paragraph in 4.4.1. In section 11.3.2, the last paragraph before the examples singles out the PUBLIC and PRIVATE attributes as different from all other attributes in that they can be respecified in a module that accesses an entity by use association. This paragraph also gives an interpretation to such respecification, stating in part: "If the name appears in a PRIVATE statement in a module, the entity is not a public entity of that module." Note specifically the phrase "of that module." The entity in question is still a public entity (of the module where it was defined). Nothing in any scoping unit other than the one where it was defined can change that. The effect of a PRIVATE statement in a module that accesses the entity by use association is just to prevent the "export" of the entity from that module - not to make the original entity private. The entity can still be accessed by using the original module where it was defined. Only in the original module containing the definition does the PRIVATE attribute have the additional interpretation of actually making the entity private. It cannot actually be a private entity of any other module; note that the sentence quoted from section 11.3.2 avoids using such wording, using instead the more awkward negative statement that it is not a public entity of that module. A similar interpretation applies to the 4th constraint after R424 in section 4.4.1: "If a component of a derived type is of a type declared to be private, either the derived type definition must contain the PRIVATE statement or the derived type must be private." If the type of a component is accessed by use association, then it must have been public in the module that defined it, so this constraint does not apply. The module MODULE M4 USE M5 PRIVATE PUBLIC X END MODULE M4 is always legal if X is a public entity of M5. Suppose that M5 is MODULE M5 USE M6 TYPE JOE TYPE(RALPH) :: J1 END TYPE TYPE(JOE) :: X END MODULE M5 If the constraint in section 4.4.1 were interpreted differently, then module M4 would have to declare at least JOE and RALPH to be public. It might conceivably also need to declare other names to be public; we cannot tell without examining at least module M6 and possibly other modules used in turn. This dependence on the details of the used modules would make an "object-oriented" style of programming difficult. Module M4 does not have any obvious reason for needing to depend on the detailed structure of the type of X. Note that a module can declare an object to be public when the type of the object is not even accessible in the module. For example MODULE M7 USE M5, ONLY :: X PRIVATE PUBLIC X END MODULE M7 Nowhere is there any restriction against this. Considering that module M7 is standard conforming, it would be strange if adding a "USE M5, ONLY: JOE" suddenly made the "PUBLIC X" statement nonconforming. EDIT: None SUBMITTED BY: G. Barber HISTORY: 93-290 m127 submitted 94-322 m131 answered, approved u.c. 95-034r1 m132 X3J3 ballot, approved 20-0; returned to subgroup for editorial changes 95-086 m132 new version after editorial changes 95-281 m135 WG5 ballot 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: 000167 TITLE: Subscripts and Substrings in Initialization expressions KEYWORDS: expression - initialization, subobject, expression - constant, expression - specification DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Can an initialization expression include arbitrary expressions for subscript or substring values if that subscript or substring value is not needed to evaluate the initialization expression? Consider the following example SUBROUTINE XX() CHARACTER *10 TEXT(20) INTEGER, PARAMETER:: I = LEN(TEXT(B+I+FNC(R))) INTEGER B, FNC ALLOCATABLE R(:) .... END SUBROUTINE The subscript of 'TEXT' is not relevant to the evaluation of the inquiry 'LEN'. There appears to be no restrictions in the standard against specifying such an arbitrary expression for the subscript. Note that with the definition of 'restricted expression' there is text [79:17-18] that indicates that any subscript, section subscript, substring starting point, or substring ending point must be a restricted expression. It would seem advisable to have an equivalent statement with the definition of an initialization expression. Section 7.1.6.1 indicates that with a subobject of a constant any subscript, must be an initialization expression (77:36-37). This restriction does not apply to this example as 'TEXT' is not a constant, so 'TEXT(B+I+FNC(R))' is not a subobject of a constant. ANSWER: No. The subscripts, section subscripts, substring starting points and substring ending points in an initialization expression must also be initialization expressions. Discussion: The restrictions for the subscripts, section subscripts, substring starting points and substring ending points as specified for subobjects of constants in constant expressions and initialization expressions should also have been applied to variables that are subobjects. Edits are supplied to correct this oversight. The code fragment shown in the question is not standard conforming. EDITS: 1. Section 7.1.6.1, in item (1) of the first list [77:17-18] change: 'constant where each subscript, section subscript, substring starting point, and substring ending point is a constant expression.' to: 'constant,' 2. Section 7.1.6.1. in the last item of the first list [77:29] change: '.' to: ',' 3. Section 7.1.6.1 at the end of the first list, in the style similar to the 'and where ...' at the end of the list in 7.1.6.2: [77:29+] add: 'and where each subscript, section subscript, substring starting point, and substring ending point is a constant expression.' 4. Section 7.1.6.1, in item (1) of the second list [77:36-37] change: 'constant where each subscript, section subscript, substring starting point, and substring ending point is an initialization expression,' to: 'constant,' 2. Section 7.1.6.1. in the last item of the second list [78:11] change: '.' to: ',' 3. Section 7.1.6.1 at the end of the second list, in the style similar to the 'and where ...' at the end of the list in 7.1.6.2: [78:11+] add: 'and where each subscript, section subscript, substring starting point, and substring ending point is an initialization expression.' SUBMITTED BY: Janice C. Shepherd HISTORY: 93-286 m127 submitted 94-333 m131 proposed response, approved u.c. 95-034r1 m132 X3J3 ballot, approved 20-0 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000168 TITLE: USE ONLY and NAMELIST KEYWORDS: use association, i/o namelist, ONLY, host association DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: If a scoping unit accesses a namelist group name by use association must all the namelist group objects also be accessible in the scoping unit? Consider the following example MODULE M1 NAMELIST /N/ I,J,K END MODULE USE M1, ONLY: N, I ... WRITE(10,N) The section in the standard on the NAMELIST statement (5.4) indicates that a namelist group name must not be PUBLIC if any of its namelist group items have the PRIVATE attribute. But in this example the namelist group name and each of its namelist group items have the PUBLIC attribute. Within the program only the namelist group name and one of its three namelist items are accessible. ANSWER: No. A namelist group name accessed by host or use association may be referenced even if not all the namelist group items are accessible by host or use association. Discussion: There is no restriction in the standard on the use of a namelist group name that is accessed by host or use association even if some or all of its namelist group objects are not accessible in the scoping unit. The code fragment in the question is standard conforming as is the following code fragment: PROGRAM HOST NAMELIST /N/ I,J,K I = 1 J = 2 K = 3 CALL INNER() CONTAINS SUBROUTINE INNER() INTEGER J ! J from the host is not accessible J = 10 ... WRITE(10, N) ... The 2nd constraint of section 5.4 is disallowing a namelist group name from being accessible outside a module if any of its namelist group objects have restrictions on their accessibility outside the module. If a module has been written such that some variables are private or have private components, the private variables or private components should not be accessible outside the module indirectly through a namelist group name. The 'ONLY' keyword on a USE statement is for limiting access to mainly avoid name conflicts in the scoping unit. It is not intended to restrict all means of access to a publicly accessible entity. In both examples, the namelist items that appeared in the NAMELIST statements, are the data objects that are being output by the WRITE statements. EDIT(S): None SUBMITTED BY: Janice C. Shepherd HISTORY: 93-287 m127 submitted 94-330r1 m131 proposed response, approved u.c. 95-034r1 m132 X3J3 ballot approved 20-0, with edit 95-281 m135 WG5 ballot 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: 000171 TITLE: Equivalence of DBLE(A) and REAL(A,KIND(0.0D0)) Intrinsics KEYWORDS: DBLE intrinsic, REAL intrinsic DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Given A of type integer, real, or complex, must the expression DBLE (A) == REAL (A, KIND(0.0D0)) always evaluate to .TRUE. for each type and kind? The text that describes the 'Result Value' of DBLE in section 13.13.27 would be easier to understand if it just stated that the result has the value REAL (A, KIND (0.0D0)). ANSWER: Yes. This result, however, is not specified in the 'Result Value' text of the two functions. Where DBLE specifies 'as much precision ... as a double precision real datum can contain.', REAL specifies a 'processor-dependent approximation'. An edit is provided. EDIT: In 13.13.27 DBLE, replace the text of the 'Result Value' section with: [205:7-11] "The result has the value REAL (A, KIND (0.0D0) )." SUBMITTED BY: Dick Weaver HISTORY: 94-018 m128 submitted 94-331 m131 Included section reference in question, approved u.c. 95-034r1 m132 X3J3 ballot approved 20-0 95-281 m135 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: 000173 TITLE: Definition of elemental intrinsic subroutine KEYWORDS: intrinsic, elemental subroutine, MVBITS DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 Section 13.2.2 defines an elemental subroutine as one that is specified for scalar arguments but may be applied to array arguments. MVBITS, 13.13.74 for example, is identified as an elemental subroutine. Section 13.2.2 asserts that, in the case of array arguments, the results are the same as would be obtained if the subroutine were applied separately to corresponding elements of each array. This assertion is true only if the input and output arguments do not overlap but there does not appear to be such a requirement. Question 1: For elemental intrinsic subroutines, is a requirement or constraint along the lines of "input and output arguments must not be associated" missing? Question 2: Alternatively, should the text about "same results" be deleted and semantics added to these subroutines similar to those for assignment? ANSWER 1: Yes. A restriction similar to the suggested restriction is missing. ANSWER 2: No. The committee decided this imposed too great a burden on Fortran processors for the functionality provided. Discussion: The text in 13.13.74 which describes the "TO" argument specifically allows FROM and TO to be the same variable (which includes s). The standard should have prohibited the FROM and TO arguments from being associated in any other way, including partial overlaps. The TO argument should also be prohibited from being associated with any other argument to MVBITS. The other intrinsic subroutines should have had similar restrictions. EDIT: Add the following sentences to the end of section 13.2.2 [183:35]: "In a reference to the intrinsic subroutine MVBITS, the actual arguments corresponding to the TO and FROM dummy arguments may be the same variable. Apart from this, the actual arguments in a reference to an intrinsic subroutine must satisfy the restrictions of 12.5.2.9." SUBMITTED BY: Dick Weaver HISTORY: 94-121 m129 submitted 95-023r1 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot failed 10-8 95-144 m133 revised response, approved u.c. 95-183 m134 X3J3 ballot passed 15-2 95-281 m135 WG5 ballot 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: 000175 TITLE: What is a "constant specification expression"? KEYWORDS: constant specification expression, expression - constant, specification expression - constant, expression - specification DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: The term "constant specification expression" is used in several places (in two constraints following R429, for example), but nowhere defined. What is the definition of "constant specification expression"? ANSWER:A constant specification expression is a specification expression that is also a constant expression. An edit is supplied to define this term. The edit is needed to make it clear that it is not sufficient for the value of the specification expression to be fixed. For example, if IC is a named constant with value 0 and I is a dummy argument, IC*I always has the value 0, but this is not a constant specification expression. EDIT: In section 7.1.6.2, add to the paragraph ahead of R734, with << >> indicating bold font,[79:19] "A <> is a specification expression that is also a constant expression." SUBMITTED BY: Dick Weaver HISTORY: 94-137 m129 submitted 95-186 m134 response proposed, approved u.c. 95-256 m135 X3J3 ballot, approved 15-1 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000176 TITLE: Definition of RANDOM_SEED KEYWORDS: RANDOM_SEED intrinsic DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: The definition in 13.13.84, RANDOM_SEED, for the optional argument GET is: "must be a default integer array of rank one and size >= N. It is an INTENT(OUT) argument. It is set by the processor to the current value of the seed." There is similar text for the PUT argument. For both cases -- "set" is used in a manner that appears to specify assignment. For similar uses of "set" see DATE_AND_TIME, IBSET, and SET_EXPONENT. -- "current value" is not the same thing as "physical representation". Setting, or assignment, of a value and necessary conversions, are described in section 7.5. "physical representation", however, was more likely intended for RANDOM_SEED. -- The shape of the seed is processor dependent and the specification for both GET and PUT results in different semantics depending on whether the processor's seed is an array of default integers, an array of some other numeric type, or a scalar. Further, the descriptions of PUT "set the seed value" and GET "set . . . to the current value of the seed" would appear to specify that: -- the processor must accept whatever is specified for a seed value when some values, 0 for example, are often not suitable -- PUT and GET can be used for global communication; assigning a value with PUT and later retrieving that same value with GET. 1. Is the following what was intended for GET? must be a default integer array of rank one and size >= N. It is an INTENT(OUT) argument. Denoting this array by "a" and the current value of the seed by "s", TRANSFER (SOURCE=s, MOLD=a) is assigned to "a". TRANSFER hides both type and shape, assigning not the current value of the seed but the physical representation of that value independent of shape. Thus the seed can be of any type and any shape. Alternatively must be a default integer array of rank one and size >= N. It is an INTENT(OUT) argument. It is assigned the physical representation of the seed value in a processor dependent manner. 2. PUT semantics are more complicated in that the argument specified for PUT may not always be suitable as a seed. Thus while the assignment semantics currently specified may not have been intended, neither is it appropriate to specify TRANSFER semantics. Are PUT semantics processor dependent? This would allow processor seeds of any type and shape. 3. Given a value specified for PUT, can processors alter that value for use as a seed? ANSWER 1: The existing wording in Fortran 90 implies that the integer array value itself is to be called a seed, regardless of the internal interpretation. EDIT 2 clarifies this. ANSWER 2: Yes, specifying PUT semantics as processor-dependent is correct. This does not mean that seeds of any type and shape are allowed. ANSWER 3: Yes, the value supplied by PUT may be altered in constructing a seed. Discussion: Edits provided in defect item 000148 describe the operation of RANDOM_SEED and RANDOM_NUMBER. Edits to the description of RANDOM_SEED arguments PUT and GET are provided here. EDITS: 1. In 13.13.84, RANDOM_SEED, PUT argument, replace the last sentence (beginning "It is used by the processor . . .") with [228:9]: "It is used in a processor-dependent manner to compute the seed value accessed by the pseudorandom number generator." 2. In 13.13.84, RANDOM_SEED, GET argument, replace the last sentence (beginning "It is set by the processor . . .") with [228:12]: "It is assigned the current value of the seed." SUBMITTED BY: Dick Weaver HISTORY: 94-142r1 m129 submitted, approved u.c. 94-221 m130 X3J3 ballot, failed 21-2 94-324r1 m131 revised response, approved 16-1 95-034r1 m132 X3J3 ballot, approved 19-1 HOLD for defect item 000148 95-155 m133 revised response, approved 12-1 95-183 m134 X3J3 ballot, failed 16-2 95-281 m135 revised response and 2nd edit, WG5 approved (N1161) 96- m135 X3J3 ballot approved, 16-0, retains WG5 approval -------------------------------------------------------------------------------- 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 -------------------------------------------------------------------------------- NUMBER: 000183 TITLE: Unambiguous procedure overloading KEYWORDS: generic interface, interface - generic, argument - dummy DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: The following example is considered to be ambiguous: INTERFACE BAD SUBROUTINE S1(A) END SUBROUTINE SUBROUTINE S2(B,A) END SUBROUTINE END INTERFACE ! BAD because the standard (14.1.2.3) requires a single argument which disambiguates both by position and by keyword (A of S2 disambiguates by position but not by keyword; B of S2 disambiguates by keyword but not by position). Note that the above is the simplest example of unambiguous overloading which the standard disallows; other cases exist where the number of nonoptional arguments is the same, e.g. INTERFACE DOUBLE_PLUS_UNGOOD SUBROUTINE S1(I,P,A) END SUBROUTINE SUBROUTINE S2(J,A,I) END SUBROUTINE END INTERFACE where S2 takes two nonoptional integer arguments and S1 takes one nonoptional integer argument, but there is still no single argument which disambiguates between them. A third example shows an (seemingly forbidden) unambiguous overloading where the number of arguments of each data type is the same: INTERFACE BAD3 SUBROUTINE S1(I,J,A,B) REAL I INTEGER B END SUBROUTINE SUBROUTINE S2(J,I,B,A) REAL I INTEGER A END SUBROUTINE END INTERFACE Was the overly strict nature of the disambiguation rules an unintentional oversight? ANSWER: Yes. A change is needed to the rules in 14.1.2.3 to avoid rejecting examples such as the first two examples shown. While the first two examples can be considered to have been incorrectly rejected by the text in the standard, the text necessary to avoid rejecting the last example is sufficiently complicated to indicate that it was specifically not included in the standard. Future versions of the standard may consider extending the language to include the third example as standard conforming. The change is to allow a difference in the number of arguments of each data type to disambiguate overloads. Discussion: To allow the third example it would be necessary to have text that would place an ordering relationship between the positional disambiguators and keyword disambiguators. Consider the following code fragment, which includes an ambiguous call. This code fragment must be nonstandard conforming. INTERFACE AMBIGUOUS SUBROUTINE S1(I,B,J,A) END SUBROUTINE SUBROUTINE S2(K,I,A,J) REAL:: I END SUBROUTINE END INTERFACE CALL AMBIGUOUS(3, 0.5, A=0.5, J=0) ! Cannot tell which of S1 or S2 to ! call EDITS: 1. In section 14.1.2.3, in the third paragraph [242:38] change "and at least one of them must have a nonoptional dummy argument that" to "and (1) one of them must have more nonoptional dummy arguments of a particular data type, kind type parameter, and rank than the other has dummy arguments (including optional dummy arguments) of that data type, kind type parameter, and rank; or (2) at least one of them must have a nonoptional dummy argument that" and indent numbers (1) and (2) to be a sublist of list item (2); changing them to be (a) and (b) respectively. 2. In section 14.1.2.3, in the text after the example [243:10-11] change "(1)" to "(2)(a)" twice change "(2)" to "(2)(b)" twice SUBMITTED BY: Malcolm J. Cohen HISTORY: 94-281r1 m130 submitted with proposed response, approved u.c. 94-306 m131 X3J3 ballot failed 17-2 94-359r1 m131 revised answer to only change conformance of first example; approved u.c. 95-034r1 m132 X3J3 ballot approved 19-1, with edit 95-281 m135 revised text in question (including 3rd example), revised response to indicate 2nd example will be valid. WG5 approved (N1161). 96- m136 X3J3 ballot approved 16-0, retains WG5 approval -------------------------------------------------------------------------------- NUMBER: 000184 TITLE: Intent of intrinsic dummy arguments KEYWORDS: INTENT, intrinsic, argument - dummy, INTENT(IN) DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: If a specific intrinsic procedure is passed as an actual argument and an interface block is specified for the dummy procedure what should be specified for the intent(s) of the dummy argument(s) of the dummy procedure? In particular it seems that the following program: INTERFACE SUBROUTINE S(P) INTERFACE REAL FUNCTION P(R) REAL R ! S1 REAL,INTENT(IN) :: R ! S2 REAL,INTENT(INOUT) :: R ! S3 REAL,INTENT(OUT) :: R ! S4 END FUNCTION END INTERFACE END SUBROUTINE END INTERFACE INTRINSIC SIN CALL S(SIN) END is standard conforming if any one of the statements S1 through S4 appears for dummy argument R. Was this intended? This seems an oversight that should be corrected by an edit to 12.4.1.2 and chapter 13. ANSWER: No. Only the version of the program in which statement S2 appears is standard conforming. Discussion: Section 12.4.1.2 states that if the interface of the dummy procedure is explicit, the characteristics of the associated actual procedure must be the same as the characteristics of the dummy procedure. Such characteristics (12.2) include the characteristics of the dummy arguments of which one is the argument intent. Unfortunately in chapter 13, the intents of most intrinsic procedure dummy arguments, including those of specific intrinsic functions such as SIN that may be passed as actual arguments are unspecified. The supplied edit corrects this deficiency by giving all such nonpointer dummy arguments INTENT(IN). EDITS: 1. Change the title of section 13.3 to be [183:36] "Arguments to intrinsic procedures" 2. add the following as a new paragraph at the end of section 13.3 [183:39+] "The dummy arguments of the specific intrinsic procedures in 13.12 have INTENT(IN). The nonpointer dummy arguments of the generic intrinsic procedures in 13.13 have INTENT(IN) if the intent is not stated explicitly." SUBMITTED BY: Graham Barber HISTORY: 94-275 m130 submitted 94-334r1 m131 proposed response, approved u.c 95-034r1 m132 X3J3 ballot, approved 17-3; returned to subgroup for determination of edit location description 95-085 m132 Changed placement of edit so that new section was not created. 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000186 TITLE: Allowed values of POSITION= and STATUS= specifiers when changing BLANK= KEYWORDS: OPEN statement, POSITION= specifier, STATUS= specifier DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION 1:What values are allowed for the POSITION= specifier when an OPEN is used to "reopen" a file and change the BLANK= etc, specifiers? Section 9.3.4, page 115, lines 20+ states: "If the file to be connected to the unit is the same as the file to which the unit is connected, only the BLANK=, DELIM=, PAD=, ERR=, and IOSTAT= specifiers may have values different from those currently in effect..." QUESTION 2:What is the current value of the POSITION= specifier? QUESTION 3:Given a sequence like: OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "ZERO", POSITION="REWIND") WRITE(10 .......... are the following OPEN statements standard conforming? (Note that POSITION="ASIS" is the default for the OPEN) 1 OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "NULL", POSITION="REWIND") 2 OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "NULL" ) 3 OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "NULL", POSITION="ASIS") A simple reading of the sentence is that 1 and 2 are standard conforming and have the same effect, but that 3 is not. The surprising feature is that execution of 1 does NOT rewind the file and that attempting to explicitly leave the file ASIS via 3 is nonstandard. It's not completely obvious that 2 is standard conforming. Section 9.3.4, page 115, line 23 states the OPEN "...does not cause any change in any of the unspecified specifiers..." so this apparently means that the POSITION= specifier is still "REWIND". However, section 9.3.4.7, page 117, line 25 states that the default value for the position specifier is "ASIS". QUESTION 4:Does the OPEN "not cause any change" from the initial specification of an unspecified specifier or does it use the default for an unspecified specifier? QUESTION 5:There is a set of similar questions for STATUS. If the STATUS= is omitted on the reopen, it defaults to "UNKNOWN". Section 9.3.4.2, page 116, lines 22+ appears to allow, for example, STATUS="NEW" on the initial OPEN but then requires either STATUS="OLD" or no STATUS= on subsequent reopens. Is this correct? ANSWER:In the following answers and discussion, the following terms are used: reOPEN (reOPEN-ing, reOPEN-ed): This is used to describe an OPEN statement for a unit which is already connected to the same file. This also applies to an OPEN statement for an external unit when the FILE= specifier is absent and the unit is already connected. properties of a connection: This is used to describe properties of a connection to an external unit that may be specified in an OPEN statement, including STATUS= and POSITION=. Note that the standard defines what the POSITION property is, but not what the STATUS property is. However, the standard does describe how the status changes during the process of an open, i.e. when STATUS="NEW" is specified, the file is created and the status changes to "OLD". Both POSITION and STATUS have a "current value", that is not necessarily the "value" specified in the OPEN statement. ANSWER 1:The standard is not clear about what values are legal for the POSITION= specifier when a file is "reOPEN-ed". The intent was to always permit a POSITION= specifier with a value of "ASIS", and to permit a value of "REWIND" only if the file was currently positioned at its initial point, and a value of "APPEND" only if the file was currently positioned at its terminal point. The edits below clarify what is allowed. ANSWER 2:The phrasing of the indicated paragraph is misleading. What the committee intended was that, except for the specifiers specifically listed, a specifier may not have a value different from those currently in effect, or in the case of the POSITION= specifier, the value must not specify a different position than the current position of the file. ANSWER 3:With the edits to the standard below, the OPEN statements labeled "2" and "3" are standard conforming for the indicated example (an OPEN followed by a WRITE followed by another OPEN, all for the same unit). The OPEN statement labeled "1" is not standard conforming in this example. ANSWER 4: The OPEN specifiers which are not specified when a file is reOPENed do not act as if the "default" value was specified for those specifiers. Instead, the property of the connection associated with that specifier is not changed by the reOPEN statement. This is described in the 6th paragraph of section 9.3.4, and this overrides the more general discussion of specifiers and their default values later in this chapter. ANSWER 5: Yes. Edits are provided to clarify what values are acceptable for the STATUS= specifier when reopening a file. Discussion: It is not absolutely clear in the Fortran 90 standard exactly what values are allowed for the POSITION= and STATUS= specifiers when a file is reOPENed. The standard is not clear what the phrase "currently in effect" in the sixth paragraph of section 9.3.4 means for the POSITION= and STATUS= specifiers. The committee intended that the phrase "currently in effect" mean the property of the connection at the time of the reOPEN, not the value of the specifier in the original OPEN statement. The language used in the standard in this area was adapted from the FORTRAN 77 standard, but some additional complications introduced by some new OPEN specifiers were not adequately addressed. When an OPEN statement is reOPENing a file, the POSITION= specifier with a value of "ASIS" is always allowed. When the file is positioned at its initial point, a reOPEN statement may have a POSITION= specifier with a value of "REWIND", and if the file is positioned at its terminal point a POSITION= specifier may have a value of "APPEND". The committee believes the standard already states this, using the intended interpretation of the phrase "currently in effect" in the 6th paragraph of section 9.3.4. An edit is included below to clarify this intent. The committee originally intended that if a STATUS= specifier was present when a unit was reOPENed, the value for the STATUS= specifier should not conflict with the "current" value in effect; however, it is very difficult to discern from the text currently in the standard what is allowed and what is prohibited. Edits are provided to clarify what values may be specified for STATUS= when reopening a file. The edits below clarify what may be specified for the POSITION= and STATUS= specifiers when reOPENing a file. EDITS: 1.In section 9.3.4, sixth paragraph [115:22], change "currently in effect." to the following: 'currently in effect. If the POSITION= specifier is present in such an OPEN statement, the value specified must not disagree with the current position of the file. If the STATUS= specifier is included in such an OPEN statement, it must be specified with a value of OLD.' 2.In section 9.3.4, add the following paragraph (note) after the 6th paragraph: [115:25+] 'Note that a STATUS= specifier with a value of OLD is always allowed when the file to be connected to the unit is the same as the file to which the unit is connected. In this case, if the status of the file was SCRATCH before execution of the OPEN statement, the file will still be deleted when the unit is closed, and the file is still considered to have the status SCRATCH.' 3.In section 9.3.4 [116:3], delete "OLD" and add the following sentence [116:3+]: 'If the STATUS= specifier has the value OLD, the FILE= specifier must be present unless the unit is currently connected and the file connected to the unit exists.' SUBMITTED BY: Dick Hendrickson for meeting 131 HISTORY: 94-297r1 m131 submitted 95-016 m132 draft response, 95-017r1 m132 draft response, approved u.c. 95-101 m133 X3J3 letter ballot, failed 17-1 95-160 m133 revised response, approved u.c. 95-183 m134 X3J3 ballot, passed 17-0 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000187 TITLE: TARGET attribute, storage association, and pointer association KEYWORDS: TARGET attribute, association - storage, COMMON block, association - pointer DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Defect item 92, the response to which has been approved by WG5 and is now in the "B" section of interpretation requests, contains an answer that is desirable but there is no text in the standard that supports the response. X3J3 was no doubt considering the following text from section C.5.3 as the base text for the response but (1) this text is in an appendix, not in the body of the standard, and (2) the text is flawed: "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." The only part of 5.1.2.8 that could reasonably be considered the "rule" to which C.5.3 refers is: "An object without the TARGET or POINTER attribute must not have an accessible pointer associated with it." This "rule" does not seem to provide the insurance mentioned in C.5.3. Rather, it seems that this sentence exists to clarify the "may" in the first sentence of 5.1.2.8. That is, it seems to be just reiterating that the following is not standard conforming: INTEGER I INTEGER, POINTER :: P P => I In actuality, there is no way that a pointer can become *pointer associated* with an object that does *not* have the TARGET (or POINTER) attribute. The confusion seems to arise when an object with the TARGET attribute is storage associated with an object that does not have the TARGET attribute. What, then, is the meaning of the sentence in 5.1.2.8 cited above? ANSWER: The sentence from 5.1.2.8 was intended to prohibit a nontarget object from being referenced both via a pointer and via the object's name within a single scoping unit, but it fails to do so. Edits are provided to add the prohibition alluded to in C.5.3. Discussion: The following example is provided to illustrate the problem and clarify the edits: PROGRAM MAIN_PROG ! Variable M (a member of blank common) does not have the TARGET ! attribute. INTEGER M COMMON M INTEGER, POINTER :: P INTERFACE SUBROUTINE SUB(P) INTEGER, POINTER :: P END SUBROUTINE END INTERFACE CALL SUB(P) M = -1 PRINT *, "M = ", M PRINT *, "P's target = ", P END SUBROUTINE SUB(P) INTEGER, POINTER :: P ! Variable M (a member of blank common) has the TARGET attribute. INTEGER, TARGET :: M COMMON M M = 100 P => M END In the main program, the storage unit represented by M and P is accessible by two different methods: the variable name M and the pointer P. The text in C.5.3 is intended to prevent this multiple accessibility but the sentence it is referencing in 5.1.2.8 is not relevant with respect to this example. Pointer P is not pointer associated with variable M in the main program. This could be demonstrated by adding the statement PRINT *, ASSOCIATED(P, M) to the main program but this statement would be invalid because M has neither the POINTER nor TARGET attribute in that scoping unit. Since there is no text in 5.5.2.3 that states that if an item in a common block has the TARGET attribute, it may correspond only with another item (in another declaration of the common block) that also has the TARGET attribute, the edits add this rule. Note that defect item 160 also quotes this same passage from C.5.3 in its question. That defect item resulted in the addition of a constraint that prohibits an object in an EQUIVALENCE list from having the TARGET attribute. Without this prohibition, there could again possibly be more than one avenue of reference to a data object in a single scoping unit. In the common block case, however, it is desirable to allow variables with the TARGET attribute so the edit adds the rule stating if a variable in a common block has the TARGET attribute, any corresponding variable in another instance of the common block with the same name must also have the TARGET attribute. REFERENCES: ISO/IEC 1539:1991 5.5.1 (as modified by defect item 160) EDITS: 1. Delete the second sentence of 5.1.2.8 [48:16-17]. 2. Insert as the (new) last paragraph of 5.5.2.3 [59:42+]: "An object with the TARGET attribute may become storage associated only with another object that has the TARGET attribute and the same type and type parameters." 3. Delete the fourth sentence of C.5.3 [269:23-25]. SUBMITTED BY: Larry Rolison HISTORY: 94-299r1 m131 submitted, with proposed response, passed 12-1 95-034r1 m132 X3J3 ballot, failed 14-6 95-281 m135 revised text in question and answer. WG5 approved (N1161) 96- m136 X3J3 ballot, approved 16-0, retains WG5 approval -------------------------------------------------------------------------------- NUMBER: 000188 TITLE: Ambiguity in Namelist Input? KEYWORDS: i/o namelist, value separator, logical value DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Suppose a namelist input list contains a logical array, followed by a variable named F (or T). If there are not enough elements to satisfy the array, then the standard doesn't seem clear whether to interpret the F= as .FALSE., discarding the '=' as superfluous, or as a new namelist group object. e.g, this input file contains 3 forms of .FALSE. for a 4 item array. PROGRAM TEST IMPLICIT NONE INTEGER F(4) LOGICAL L(4) NAMELIST /TRACERS/ L, F READ (9, TRACERS) END --------------- input file ----------------- &TRACERS L=.FALSE.,.F.,F, F=0,1,2,3 / -------------------------------------------- 10.9.1.2, 3rd paragraph (page 152) states: "When the name in an input record represents an array variable ... The number of values following the equals must not exceed the number of list items in the expanded sequence, but may be less; in the latter case the effect ..." so a full list is not needed. 10.9.1.3 3rd paragraph (page 153) states: "When the next effective item is of type logical, the input form of the input value must not include slashes, blanks, or commas among the optional characters permitted for L editing (10.5.2) " and points to the description of the input field 10.5.2 2nd paragraph (page 143) states: "The input field consists of optional blanks, optionally followed by a decimal point, followed by a T for true or F for false. The T or F may be followed by additional characters in the field. Note that the logical constants .TRUE. and .FALSE. are acceptable input forms......" describes the forms allowed on input. The 'additional characters' is the sticky point. This leads to the questions: Question 1) In the example above, is the F=0 interpreted as a .FALSE. or a namelist group item? Question 2) Does the answer to (1) change if the equals sign is surrounded by blanks (value separators) e.g.: &TRACERS L=.FALSE.,.F.,F, F = 0,1,2,3 / Question 3) It appears the 3rd paragraph in 10.9.1.3 taken with 10.5.2 is intended to allow F in a list to be interpreted as .FALSE., (e.g.: F,) but it is difficult to construe the text this way. If the input file was &TRACERS L=.FALSE.,.F.,F/ F = 0,1,2,3 / would the slash terminate the namelist input or would 'F/' be an illegal logical field? Shouldn't the paragraph be rewritten to say blank, comma or slash in a logical field are interpreted as value separators? Note: the consequence to the implementation is lookahead at inconvenient moments. ANSWER 1: It is intended to be interpreted as the start of a new namelist name-value subsequence. The name before the "=" may be any name in the . Edits are supplied to resolve the ambiguity. ANSWER 2: No. The presence of optional blanks as described in section 10.9 does not affect the interpretation. ANSWER 3: The "/" terminates the namelist record. "/" is not permitted as one of the optional characters following the "T" or "F" in a logical constant (10.9.1.3, 3rd paragraph). Therefore, the "/" is a value separator (10.9, 10.8) and it causes termination of the namelist input statement as described in the 4th paragraph of section 10.9.1.2. Discussion: The committee intended that a name-value subsequence should always be identifiable by looking for an object name or subobject designator, followed by an equal sign, with optional blanks permitted before and after the equal sign. The committee attempted to eliminate all ambiguities between the start of a name-value subsequence and a value by limiting the forms of acceptable input values. The particular case mentioned in Question 1 was overlooked. The edit below fixes this ambiguity. EDIT: In section 10.9.1.3, 3rd paragraph [153:12], change "blanks," to "blanks, equals,". SUBMITTED BY: David Phillimore. HISTORY: 94-298 m131 submitted 94-345 m131 response, approved u.c 95-034r1 m132 X3J3 ballot approved 20-0, with edits 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000189 TITLE: Module name / local name conflict KEYWORDS: name - class, use association, global entity DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: The question in this defect item is a variation on defect item 127. Consider the following program: MODULE M1 INTEGER I END MODULE MODULE M2 USE M1 INTEGER J END MODULE MODULE M3 USE M2 INTEGER M1 END MODULE Is there a conflict between the global module name M1 (the first module) and the locally declared variable name M1 (in the last module)? ANSWER: No. Discussion: The declaration of the local variable M1 is not in conflict with module name M1 because module names are not use associated. From 11.3.2: The USE statement provides the means by which a scoping unit accesses named data objects, derived types, interface blocks, procedures, generic identifiers (12.3.2.1), and namelist groups. Note that a module is not a procedure. Naming a module in a scoping unit (on the USE statement) causes the module name to become known to that scoping unit (as opposed to the module name being accessed from the module) and thus conflicts with the module name are possible within the scoping unit that names the module on the USE statement. And this was the question addressed by Interpretation Request 127. However, since a module name is NOT accessed via a USE statement, module name M1 is not known to module M3 and therefore there is no conflict with the declaration of variable M1 in M3. EDITS: None SUBMITTED BY: Larry Rolison HISTORY: 94-301 m131 submitted with proposed response, approved u.c. 95-034r1 m132 X3J3 ballot, approved 20-0 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000192 TITLE: Ambiguity of dummy procedures in interface bodies KEYWORDS: dummy procedures, interface bodies DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: It appears that it may not be possible to identify from a procedure interface body which, if any, of its dummy arguments are dummy procedures. This arises from the fact that it is not necessary to give an explicit interface for dummy procedures, or even to specify the EXTERNAL attribute for them (the latter only being necessary for procedures that are used as actual arguments). Even if it were mandatory to (at least) specify EXTERNAL for dummy procedures, this would still not resolve them into subroutines and functions, given that typing may be implicit. For example, in: INTERFACE FUNCTION F (A,B,C) END FUNCTION F END INTERFACE each of the arguments could be a dummy scalar variable, a dummy function or a dummy subroutine. It appears that an explicit interface should identify dummy procedures and their nature (function or subroutine, and result type in the former case). Section 12.2 of the F90 standard ("Characteristics of Procedures") does not seem to give much guidance: section 12.2.1.2 states that a dummy procedure's characteristics only include its characteristics *as* a procedure if its interface is explicit, which is not very illuminating. Question 1: Should a procedure interface body unambiguously identify dummy procedures and their nature (i.e. function or subroutine)? Question 2: Is the EXTERNAL attribute mandatory for dummy procedures in an interface body, if they do not themselves have explicit interfaces? Question 3: If so, how are dummy functions and subroutines distinguished given that typing may be implicit? ANSWER: Answer 1: No. The interface body must identify each dummy argument that is a procedure by means of one of the following : -- an EXTERNAL statement for the argument -- a type declaration statement for the argument and the argument also has the EXTERNAL attribute -- an interface block for the argument. Where an interface block is present the interface body will allow the disambiguation of the dummy procedure as a subroutine or function. Where a type declaration statement is present the dummy procedure is identified as a function. Where only an EXTERNAL statement is present it is not possible to disambiguate the procedure as a subroutine or function. Answer 2: Yes. Answer 3: A dummy argument that is a procedure may be identified as a function by its appearance in a type declaration statement or in a function statement within an interface body for the argument. A dummy argument that is a procedure may be identified as a subroutine by its appearance in a subroutine statement within an interface body for the argument. Discussion: The necessity to disambiguate dummy arguments that are procedures from dummy arguments that are not procedures is described in the response to defect item 000063. Section 12.3.2.1 (page 168) states that an interface body specifies all of a procedure's characteristics. Section 12.2.1.2 indicates that the characteristics of a dummy procedure are the explicitness of its interface, its characteristics as a procedure if the interface is explicit and whether it is optional. So, if a procedure P has a dummy procedure with an implicit interface the characteristics of the dummy procedure do not include whether it is a function or subroutine. Therefore it is not necessary that an interface block for P disambiguate the dummy procedure as a function or subroutine. If by contrast the interface for the dummy procedure is explicit in the scope of P, any interface body for P must include a nested interface body for the dummy procedure. This is indicated in the standard from the text of sections 12.2, 12.2.1.2 and 12.3. Section 12.3 specifies that the characteristics of a procedure are fixed. Section 12.2 indicates that the characteristics of a procedure include the characteristics of its dummy arguments. Finally, section 12.2.1.2 states that the characteristics of a dummy procedure include the explicitness of its interface. So any interface block for P must incorporate a nested interface block for the dummy procedure that specifies all these characteristics. EDITS: None SUBMITTED BY: John Merlin HISTORY: 94-307 m131 submitted 95-054r1 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot approved, 14-4, with edits applied 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000193 TITLE: Pointer actual arguments with the OPTIONAL attribute KEYWORDS: optional, POINTER attribute TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION : Section 12.5.2.8 states the following about an optional dummy argument that is not present (as modified by Corrigendum 1): [179:39-40] "Except as noted in (5) above, it may be supplied as an actual argument corresponding to an optional dummy argument." Section 7.1.4.1 states (as modified by Corrigendum 2) : [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, or as the target in a pointer assignment statement." Consider the following example : PROGRAM MAIN CALL INNER() CONTAINS SUBROUTINE INNER(PARG) OPTIONAL :: PARG POINTER :: PARG INTERFACE SUBROUTINE SUB(TARG) OPTIONAL :: TARG END SUBROUTINE END INTERFACE CALL SUB(PARG) END SUBROUTINE END PROGRAM In this example, PARG is an optional dummy argument that is not present and it is being supplied as an actual argument corresponding to an optional dummy argument. On the other hand, PARG is a pointer that is not associated with a target, therefore it should not be supplied as the actual argument corresponding to a dummy argument that is not a pointer. If a pointer dummy argument is not present, may it be specified as the actual argument corresponding to a dummy argument that is not a pointer? ANSWER : No. An optional dummy argument that is a pointer and is not present must not be supplied as an actual argument corresponding to a dummy argument that is not a pointer. This restriction should have been included in the list within section 12.5.2.8 Edits are supplied to correct this omission. EDITS: 1. In Section 12.5.2.8, add the following to the numbered list after the list item added by Corrigendum 1 [179:38+]: "(6) If it is a pointer, it must not be supplied as an actual argument corresponding to a nonpointer dummy argument other than as the argument of the PRESENT intrinsic function." 2. In Section 12.5.2.8, in the text added by Corrigendum 1 to the last sentence of the section [179:39]: change "in (5)" to "in the list" SUBMITTED BY: Janice C. Shepherd HISTORY: 95-097 m133 submitted, with proposed response, approved u.c. 95-183 m134 X3J3 ballot, passed 16-1 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000195 TITLE: INQUIRE with preconnected files KEYWORDS: INQUIRE statement, preconnected file DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: If unit 3 is preconnected to file PDG, which does not exist, then consider the following Fortran 90 source: PROGRAM PETE CHARACTER*50 FM INQUIRE(UNIT=3, FORM=FM) END The notes (section C.9.4, page 278, lines 11-17) state that 'For a preconnected file that does not exist, a form may be established or the establishment of a form may be delayed until the file is created'. QUESTION 1: Where in the actual standard is there anything that substantiates the notes that the form may be established as a preconnection property or that it may be delayed? QUESTION 2: If a processor delays the establishment of a form until the file is created, then what is returned in variable FM in the program above? The standard does not seem to cover this case, all it covers is a) if the connection is for formatted b) if the connection is for unformatted c) if there is no connection There seem to be similar problems with INQUIRE with RECL, BLANK and DELIM specifiers on a similar file. ANSWER 1: The standard does not clearly state that the establishment of a form may be delayed. It is inferable from other text and the lack of an explicit prohibition. ANSWER 2: The standard does not specify what is returned in the variable FM in this case. Therefore, the processor is free to choose any value. Some of the other specifiers may also return processor dependent values for this example. Any property of the connection or file that depends on: 1) the "form" or "access" of the file connection, or 2) is only allowed for a file with a particular "form" or "access", may have a processor dependent value returned by the INQUIRE statement for that property, for this particular example. Discussion: In several places the standard refers to a form being in the allowed set of forms. A processor may allow (but is not required to allow) some files to be OPENed with either a FORM value of FORMATTED or UNFORMATTED. In section 9.3.4.4 (OPEN statement, FORM= specifier), the standard states: "For a new file, the processor creates the file with a set of allowed forms that includes the specified form". This implies that a processor may delay establishing a form for a file until the file is created. And in section 9.3.2, 3rd paragraph, the standard states: "A file may be connected and not exist. An example is a preconnected external file that has not yet been written (9.2.1.1)." So, a preconnected file need not exist until the file is referenced in a data transfer statement, and the establishment of the form may be delayed until the the file is created. If the processor delays establishing a form until the file is created, the first data transfer statement to reference a non-existent preconnected file will establish the form, and it is incumbent upon the user to only use that form. EDITS: None. SUBMITTED BY: Peter Griffiths HISTORY: 95-014 m132 submitted 95-018 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot approved, 16-2, with edits applied 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000198 TITLE: Characteristics of dummy procedures KEYWORDS: argument - optional, characteristics, dummy procedures, interface - explicit DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 12.4.1.2 "Argument associated with dummy procedures" states: "If the interface of the dummy procedure is explicit, the characteristics of the associated actual procedure must be the same as the characteristics of the dummy procedure (12.2)." Section 12.2.1.2 "Characteristics of dummy procedures" states: "The characteristics of a dummy procedure are the explicitness of its interface (12.3.1), its characteristics as a procedure if the interface is explicit, and whether it is optional (5.1.2.6, 5.2.2)." This would imply that the following two examples are not standard conforming, as the characteristics of ARG1 are not the same as the characteristics of ARG2, and ARG2 has an explicit interface. Example 1: SUBROUTINE S(ARG1) EXTERNAL ARG1 INTERFACE SUBROUTINE SS(ARG2) INTERFACE FUNCTION ARG2(I) END FUNCTION END INTERFACE END SUBROUTINE SS END INTERFACE CALL SS(ARG1) ! ARG2 has an explicit interface and that is ! one of its characteristics but ARG1 has an ! implicit interface as one of its characteristics END SUBROUTINE S Example 2: SUBROUTINE T(ARG1) OPTIONAL ARG1 INTERFACE FUNCTION ARG1(I) END FUNCTION END INTERFACE INTERFACE SUBROUTINE TT(ARG2) INTERFACE FUNCTION ARG2(I) END FUNCTION END INTERFACE END SUBROUTINE TT END INTERFACE IF (PRESENT(ARG1)) CALL TT(ARG1) ! ARG1 is optional and that ! is one of its characteristics. ARG2 is not ! optional and that is one of its characteristics. END SUBROUTINE T Are the code fragments standard conforming? ANSWER: Yes, both code fragments are standard conforming providing in the first code fragment that ARG1 is associated with a function whose arguments and function result are consistent with those of ARG2. Discussion: In the text cited from 12.4.1.2, the reference to 12.2 was there to indicate that the requirement is that the characteristics of the dummy procedure as a procedure match the characteristics of the actual procedure as a procedure. The other characteristics of a dummy procedure (the explicitness of its interface and whether it is optional) were not meant to be included in the reference. The characteristics of a procedure are: - the classification of the procedure as a function or subroutine - the characteristics of its arguments - the characteristics of its result value if it is a function In the second code fragment the interface for ARG1 shows that these three characteristics are the same for ARG1 and ARG2. In the first code fragment these three characteristics of ARG1 are not known. For this code fragment to be standard conforming these three characteristics of any procedure associated with ARG1 must be the same as those of ARG2. An edit is included to clarify the text in 12.4.1.2. EDIT: Section 12.4.1.2, replace the second paragraph with [173:35-36] "If the interface of the dummy procedure is explicit, the characteristics listed in 12.2 must be the same for the associated actual procedure as for the corresponding dummy procedure." SUBMITTED BY: Janice C. Shepherd HISTORY: 95-042 m132 submitted, with proposed response, approved 9-4, 95-067 m132 alternate edit proposed, approved u.c. 95-101 m133 X3J3 ballot, failed 13-5 95-187 m134 alternate response proposed, approved u.c. 95-256 m135 X3J3 ballot, approved 15-0 95-281 m135 WG5 ballot approved ------------------------------------------------------------------------------ NUMBER: 000199 TITLE: Kind Type Parameters and the DELIM= specifier KEYWORDS: kind type parameter, i/o list-directed, i/o namelist DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Should defect item 131, which clarified that kind parameters should not appear in formatted input and output records, have deleted the text about in section 9.3.4.9 also? ANSWER: Yes. This is corrected by the edit below. Discussion: Defect item 131 revised numerous sections in chapter 10, where the form of values in formatted records was described, but similar text in chapter 9 was missed. The intent of defect item 131 was to prohibit a from appearing as part of a nondefault character constant in formatted records. Defect item 131 should have deleted the text in chapter 9, section 9.3.4.9, in the discussion of the DELIM= specifier, where the standard states that a nondefault character constant written to a list directed or namelist output record will be preceded with a and an underscore, whenever the file was opened with certain values for the DELIM= specifier. EDITS: In section 9.3.4.9, first paragraph, delete the 4th sentence [117:40-41]: "If APOSTROPHE or QUOTE is specified, a and underscore will be used to precede the leading delimiter of a nondefault character constant." SUBMITTED BY: Rich Bleikamp HISTORY: 95-181 m134 submitted with proposed response, approved u.c. 95-256 m135 X3J3 ballot, approved 16-0 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000201 TITLE: SELECTED_REAL_KIND result KEYWORDS: SELECTED_REAL_KIND, intrinsic, result DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: The Result Value portion of the description of SELECTED_REAL_KIND states in part: "The result has a value equal to a value of the kind type parameter of a real data type with decimal precision, as returned by the function PRECISION, of at least P digits ..., or if no such kind type parameter is available on the processor, the result is -1 if the precision is not available..." When SELECTED_REAL_KIND is invoked with a P value of -1, some vendors return a positive value as the result (almost certainly because they've focused on the phrase "of at least P digits" in the above quote from the standard) and some vendors return -1 (almost certainly because they've focused on the phrase "the result is -1 if the precision is not available" in the above quote from the standard). Question 1: Is either one of these results "more correct" than the other? Question 2: Are both answers acceptable? ANSWER 1: Yes. For this example, the processor should return a positive value. ANSWER 2: No. Discussion: The phrase "if the precision is not available" in section 13.13.93 of the standard is confusing. Edits are supplied to clarify the intent. EDITS: In section 13.13.93, in the paragraph prefaced with "Result Value:" [232:6-7] change "if the precision is not available" to "if the processor does not support a real data type with a precision greater than or equal to P" change "if the exponent range is not available" to "if the processor does not support a real data type with an exponent range greater than or equal to R" and change "if neither is available" to "if neither is supported" SUBMITTED BY: Larry Rolison HISTORY: 95-175 m134 submitted 95-281 m135 response, approved by WG5 (N1161) 96- m136 X3J3 ballot approved 15-1, retains WG5 approval -------------------------------------------------------------------------------- NUMBER: 000203 TITLE: Scope of operator/assignment symbols KEYWORDS: intrinsic/defined operators/assignment, local/global entities DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION 1: Section 14.4 (Scope of operators) states that "The intrinsic operators are global entities." and that "A defined operator is a local entity.". But a defined-operator (R311) may be an extended-intrinsic-operator (R312) which in turn is an intrinsic-operator (R310). This means that if intrinsic operators are global entities, so are at least some of the defined operators, so the second quotation given above cannot be true. Is this correct? PROPOSED EDIT: Add " that is not an extended intrinsic operator" after "A defined operator" in [F90,245:30]. QUESTION 2: In Section 14.4, the sentence "Within ..." applies to the first sentence only. Defined-operators (other than extended-intrinsic-ops) have no intrinsic meaning and so "additional operations" makes no sense. Is this correct? PROPOSED EDIT: Move sentence 2 to the end of 14.4. QUESTION 3: Section 14.5 (Scope of the assignment symbol) does not address the replacement of the intrinsic derived type assignment operation, as defined in 7.5.1.2 and 12.3.2.1.2. Is this correct? PROPOSED EDITS: Add ", or replace the intrinsic derived type assignment operations" after "operations" in [F90,245:34]. QUESTION 4: The entities under consideration in 14.4 and 14.5 are the operator and assignment SYMBOLS. These are to be distinguished from the associated OPERATIONS in the same way that a generic name is to be distinguished from the specific names it comprises. Is this correct? PROPOSED EDITS: in [F90,245], replace: * line 29: "operators" => "operator symbols" * line 30: "operators" => "operator symbols" * line 30: "operator" => "operator symbol" * line 31: "operator" => "operator symbol" * After the "Within ..." sentences (lines 30,33), add "The procedures corresponding to these operations are local entities." (The intrinsic operations have no "specific" entities associated with them and so need not be mentioned. If they had, these would be global entities.) ANSWERS: ANSWER 1: Yes. An edit is supplied below to clarify that some defined operators are indeed global entities. ANSWER 2: Yes. Although the word "additional" only applies to the first sentence, the proposed edit does not substantially improve the clarity, and the existing text is not in error. ANSWER 3: Yes. An edit is supplied below which adds the case of redefining the assignment operation when the two arguments have the same derived type. ANSWER 4: Yes. However, the current use of the words "operator" and "operations" already makes this distinction in a sufficiently precise manner. EDITS: 1.In Section 14.4, after "A defined operator" [245:30], add "that is not an extended intrinsic operator" 2.In Section 14.5, after "operations" [245:34], add ", or replace the intrinsic derived type assignment operation" SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: 95-254 m135 submitted 95-281 m135 response, WG5 approved (N1161) 96- m136 X3J3 ballot approved 15-1, retains WG5 approval --------------------------------------------------------------------------------