Archive: 96-006r2/A0 -------------------------------------------------------------------------------- NUMBER: 00000e TITLE: Rejected Minor edits and corrections KEYWORDS: typographical errors DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Should the following be added to the list of edits? 8. In 13.13.85 RANGE change 'Returns the decimal exponent range in the model ...' to 'Returns the upper bound of the decimal exponent range of the model ...' [228:20] Rationale(1): a range has two values; RANGE returns only one. Rationale(2): there is not a decimal range in the model, see 13.7.1, but a decimal range can be calculated. Thus the change from 'in' to 'of'. 9. In 13.13.79 PRECISION change 'Returns the decimal precision in the model ...' to '............................. of .............' [226:4] Rationale: same as for RANGE, above. ANSWER: This item collects failed "minor edits and corrections" so that the reasons for failing them can be recorded for historical purposes. No further voting is needed for items in this list. No, 8 and 9 should not be added. The use of 'range' is consistent with other uses in the standard and is meant to convey an entire range of values not just 2. The change from 'in' to 'of' is too small a change to be included at this time and would best be addressed in a future standard. EDITS: None SUBMITTED BY: HISTORY: 94-028 m128 additional items 8-9 ------------------------------------------------------------------------------- NUMBER: 000049 TITLE: Characteristics of function results KEYWORDS: characteristics, function result, ENTRY statement, exact dependence, association - partial, association - entry DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Given a character function with an ENTRY statement, both results must have the same characteristics or be scalars without the POINTER attribute and have identical length. Therefore: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN,ENT ... ENTRY ENT(M,N) ... END FUNCTION is standard conforming. Question 1: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=M+N)::ENT ... ENTRY ENT(M,N) ... END FUNCTION Is the code above standard conforming? Question 2: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=N+M)::ENT ... ENTRY ENT(M,N) ... END Is the code above standard conforming? Question 3: FUNCTION FUN(M) CHARACTER (LEN=M+M)::FUN CHARACTER (LEN=M*2)::ENT ... ENTRY ENT(M) ... END Is the code above standard conforming? Question 4: What is the meaning of the phrase "the exact dependence on the entities" in section 12.2.2? ANSWER: Answer 1. Yes Answer 2. Yes Answer 3. Yes Answer 4. The sentence containing the phrase "the exact dependence on the entities" in section 12.2.2 is intended to convey that in those cases where the shape or character length type parameter is not constant, the corresponding characteristic of the function result is not a value but the way the value is determined when the procedure is invoked. Discussion: Only the mapping from program state to value is significant, not the particular form in which that mapping is expressed. In question 3, for example, it is a characteristic of FUN and ENT that their lengths are twice the value of M. It is not required that the expressions of this mapping be identical, only that they yield the same results. Thus, twice the value of M could be expressed as M+M for FUN and as M*2 for ENT. The phrase "the exact dependence on the entities in the expression is a characteristic" is used to give the processor the freedom to evaluate lengths and bounds in any convenient manner. Since the characteristics must be the same, the phrase implies, as a minimum, that the expressions be algebraically equivalent and use the same variables. In an example such as: FUNCTION FUN(M) CHARACTER (LEN=M)::FUN CHARACTER (LEN=M + 0*K)::ENT ... ENTRY ENT(M, K) ... END FUN and ENT do not have the same characteristics since their dependence on "K" is different. Indeed, if on entry to FUN the length of FUN or ENT were evaluated using the expression for the length of ENT the evaluation would fail since K is not associated with a value. Clearly, it can be extremely difficult to determine on a static basis whether two expressions of a mapping are consistent, and there is no requirement in the standard that this be done. It would be possible to check during execution that the values expressed are identical each time such a procedure is invoked, but it is expected that a more typical application of this requirement would be to assume that it has been met and use one expression of this mapping as the basis for computing attributes of all of the result variables. REFERENCES: ISO/IEC 1539:1991 (E) section 12.2.2 & 14.6.3.3 EDITS: None SUBMITTED BY: Y. Yoshida, X3J3/92-051 (121-ADT-11) pp.-13 HISTORY: 92-109A m121 Approved 19-0 92-313 m123 response to ballot comments and approved by uc 93-105 Revised in response to ballot comments 93-152 m125 New edit, rejected 94-059 m128 New edit, 94-252 m130 New response without edits, approved u.c. 94-306 m131 X3J3 ballot approved 18-1 95-044 m132 WG5 ballot failed, text in Answer 4 and discussion needs revision -------------------------------------------------------------------------------- NUMBER: 000070 TITLE: Characteristics specified by interface bodies KEYWORDS: characteristics, array bounds, array shape, function result DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 12.3.2.2 indicates that an interface body specifies all of a procedure's characteristics and that the characteristics must be consistent with those in the procedure definition. Are the following code fragments standard conforming? (a) PROGRAM FRED INTERFACE SUBROUTINE SUB (ARR,J) INTEGER ARR(1:) END SUBROUTINE END INTERFACE INTEGER ARR(10) CALL SUB(ARR,2) END PROGRAM SUBROUTINE SUB(ARR, J) INTEGER ARR(J:) ... END SUBROUTINE SUB (b) FUNCTION C1( ) CHARACTER(*) C1 ... END FUNCTION C1 FUNCTION C2(N) CHARACTER(N) C2 ... END FUNCTION C2 SUBROUTINE CALLER( ) INTERFACE FUNCTION C1( ) CHARACTER(*) C1 END FUNCTION FUNCTION C2(N) CHARACTER(2) C2 END FUNCTION END INTERFACE CHARACTER(5) CC CC=C1( )//C2(2) ANSWER: (a) This example is standard conforming. (b) This example is not standard conforming. Discussion: (a) 12.2.1.1 states that the characteristics of a dummy data object include its shape, and that if the shape is assumed then that is a characteristic. Section 2.4.5 states that the shape of an array is determined by its rank and extent in each dimension (but not by its bounds, 5.1.2.4.2). Both the interface block for SUB and the definition of SUB describe the shape of ARR as assumed, so they are describing the same shape, and the program is standard conforming. It is possible to read the second sentence in 12.2.1.1 as requiring bounds to match. This was not intended. An edit to that section (defect item 49) has clarified that it is the shape resulting from the bounds specifications that is a characteristic and not the bounds themselves. (b) Section 12.2.2 states that the characteristics of a function include whether or not the function result value is a character of assumed length. So the interface body for function C1 must indicate that C1 is of assumed length. However, item (3) in 5.1.1.5 indicates that scoping units that invoke an external character function of assumed length must have access to a declaration of the function name with a length type parameter value other than *. An edit is included to clarify this restriction. In addition, the interface for C2 does not conform to the standard as the length of C2 specified as 2 is not consistent with the length specified as N within the function definition. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.4.5, 5.1.1.5, 5.1.2.4.2, 12.2.1.1, and 12.2.2. EDITS: In section 5.1.1.5 item (3), add to the end [43:5]: "Note that the interface for such a function cannot be specified in an interface body." SUBMITTED BY: Graham Barber (a), Janice Shepherd (b) HISTORY: 92-264 Question (a) originally posed 92-46 Question (b) originally posed in e-mail collection ui 48 (jw note) 92-283 Response proposed m123 Approved by unanimous consent 93-018 Response questioned by John Reid in 93-103 Revised response proposed m124 Approved by unanimous consent 93-111 m125 ballot, return to subgroup, Leonard comment, coordinate with 0000049? 94-060 m128 New edit in 0000049 referenced -------------------------------------------------------------------------------- NUMBER: 000096 TITLE: Definition of "Declaration" KEYWORDS: declaration, specification DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: "Declaration" is a significant concept of Fortran 90. Section 5 is titled "Data object declarations and specifications" and what were in FORTRAN 77 "type statements" are now "type declaration statements". 5.1.1 states "A type specifier specifies the type of all entities declared in an entity declaration list." Nowhere, though, is there a definition of "declaration". What does it mean, in Fortran 90, to "declare" something? ANSWER: The edits below add a definition of "declaration" and, for clarity, also add a definition of "specification". Edits related to these definitions are also provided. REFERENCES: EDITS: 1. Replace the text of 2.5.3 "Declaration" [16:13-18] with: A data object declaration specifies the creation, attributes, and lifetime of the object. Every data object must be declared. Declarations can be explicit or contextual. Data object attributes not specified explicitly are determined implicitly. A declaration of a data object of derived type is also a declaration of all of its components. In a scoping unit, if a name appears as: (1) an object-name in an entity-decl in a type-declaration, SAVE, POINTER, or TARGET statement (2) a named-constant in a named-constant-def in a PARAMETER statement (3) an array-name in a DIMENSION or ALLOCATABLE statement (4) a variable-name in a common-block-object in a COMMON statement (5) the name of a variable that is wholly or partially initialized in a DATA statement (6) the name of an object that is wholly or partially equivalenced in an EQUIVALENCE statement (7) a dummy-arg-name in a FUNCTION, SUBROUTINE, ENTRY or statement-function statement (8) a result-name in a FUNCTION or ENTRY statement then those statements constitute an explicit declaration of a data object with that name in that scoping unit. otherwise: if a name that is not a procedure name, module name, program name, generic identifier, common block name, namelist group name, construct name, or derived type name, appears in any statement and that name is not the name of a data object accessed by host or use association then those appearances constitute a contextual declaration of a data object with that name in that scoping unit 2. In section 5.2.9 "DATA statement", in the fifth constraint following R537 [52:31-32]: delete "made accessible by use or host association," as now redundant with the definitions of use and host association. 3. In 11.3.2 "USE statement", in the paragraph beginning "If two or more" in the third sentence [158:29-31]: change: through to: through explicit declaration, 4. In 12.1.2.2.1 "Host association" replace items 5 though 12 with the one new item [164:8-17] (5) An explicitly declared data object (2.5.3); 5. In Annex A, add to page 256 after "datum" [256:10+] Declaration(2.5.3): A declaration specifies the existence of a data object. 6. In Annex A, add to page 260 after "size" [260:14+] Specification: A specification assigns attributes and properties to names. SUBMITTED BY: Dick Weaver HISTORY: 92-232 Submitted 92-232r Draft response, withdrawn 93-144 m125 unanimous consent 93-255r1 m127 ballot failed 16-7 94-103 m128 revised response, approved uc 94-116 m129 X3J3 ballot failed 16-7 94-223 m130 revised response 94-335 m131 alternate response proposed, withdrawn -------------------------------------------------------------------------------- NUMBER: 000100 TITLE: ASSOCIATED intrinsic and zero-sized objects KEYWORDS: ASSOCIATED intrinsic, zero-sized objects, target, pointer DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: What is the behavior of the ASSOCIATED intrinsic function for zero-sized arguments? Question 1: Can the single argument form of the ASSOCIATED intrinsic return true as its result if the argument's target is zero sized? Question 2: Can the two-argument form of the ASSOCIATED intrinsic return true when both arguments are zero sized? The following need answers only if the answer to question 2 is yes. Question 2a: If the arguments to ASSOCIATED are zero sized but of rank greater than one, must the extents of each dimension be the same for ASSOCIATED to return true? For example, what is printed by the following program? PROGRAM HUH REAL, DIMENSION(:,:), POINTER :: P1, P2 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(10:9:1, :) P2 => A(:, 10:9:1) PRINT *, ASSOCIATED (P1, P2) END Question 2b: In the following example, rank, shape, type, kind type parameters, and extent of dimensions of the zero-sized arguments to ASSOCIATED match, but the second argument is not the same as the right hand side of the previous pointer assignment statement. What is the output of this program? (Does a notion of "base address" come to play for zero-sized objects as it does for nonzero-sized objects?) PROGRAM HMMM REAL, DIMENSION(:,:), POINTER :: P1 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(:, 2:1:1) PRINT *, ASSOCIATED (P1, A(:, 3:2:1)) END ANSWERS: Answer 1: The one-argument form of ASSOCIATED returns a result of true if the pointer actual argument is currently associated with a target, even if the target is zero sized. Answer 2: No; if either argument is zero sized the result is false. The edits in defect item 000027 clarify the intent. Answer 2a: The result is false because P1 and P2 each are zero sized. Answer 2b: The result is false because the arrays are of zero size. Discussion: The reasons for having the ASSOCIATED function return false for zero-sized arrays is based on an analogy with sharing storage and how assignment works. In normal English we understand the concept of "totally associated" and "partially associated". If two things are totally associated then doing something to one of them does the exact same thing to the other. If two things are partially associated then doing something to one of them does something to the other. Section 14.6.3.3 hints at this by discussing "totally associated" in terms of "the same storage sequence". After executing assignment statements like I = values J = different_values we would call I and J associated if it were no longer true that I is equal to values. Zero-sized arrays are the end case where doing "something" to them is equivalent to doing nothing to them. And in the example above we would still have I is equal to values after the assignment if both I and J were zero-sized but would otherwise appear to be associated. We could also conclude that after the pair of assignment statements above executed we would have I is equal to different_values if I and J were zero sized, since the comparison operators return true for zero-sized objects. However, on balance it seems better to view the comparison with the initial conditions, not the potential changed conditions. As a practical matter, sensible use of the ASSOCIATED function with zero-sized arrays will usually require user special casing of the results. EDITS: None. SUBMITTED BY: Jon Steidel - X3J3/92-240 HISTORY: ui 114 (jw note) 92-240 m123 Submitted 93-035 m124 response, adopted by unanimous consent 93-111 m125 ballot, return to subgroup based on Hirchert, Maine comments. Also see Ellis comment for 000108 93-138r m125 revised response adopted 11-8. 93-255r1 m127 ballot passed 21-3 94-160 m129 WG5 ballot, failed 94-253r3 m130 revised response, approved u.c. 94-306 m131 X3J3 ballot, approved 15-4 95-044 m132 WG5 ballot, approved, with Reid edit 95-306r1 m135 withdrew edits as defect item 27 supplies better edits, approved u.c. 96- m136 X3J3 ballot, approved 15-1 -------------------------------------------------------------------------------- NUMBER: 000140 TITLE: TARGET attribute for a derived-type object with a pointer component KEYWORDS: POINTER attribute, TARGET attribute, structure, structure component DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 6.1.2 (page 63) states: "A structure component has the INTENT, TARGET, or PARAMETER attribute if the parent object has the attribute." A constraint following R505 (page 40) states: "Constraint: If the POINTER attribute is specified, the TARGET, INTENT, EXTERNAL, or INTRINSIC attribute must not be specified." This would seem to imply that a derived-type object with a pointer component could not have the TARGET attribute. Though it is informative, Annex C.4.6 (page 267) contains the following example: "TYPE CELL INTEGER :: VAL TYPE (CELL), POINTER :: NEXT_CELL END TYPE CELL TYPE (CELL), TARGET :: HEAD TYPE (CELL), POINTER :: CURRENT ... CURRENT => HEAD" which allows the static head of a linked list or tree. Does the structure component HEAD % NEXT_CELL contradict the text cited above from section 6.1.2 or the cited constraint following R505? ANSWER: No, the component reference does not contradict either the constraint or the cited text from 6.1.2. The cited text from 6.1.2 is not needed and an edit provided deletes it. Discussion: The constraints that follow a syntax rule, or a set of syntax rules, are syntactic constraints and apply only to the syntax rules they immediately follow. Thus, the constraints that follow rules R501 through R505 at the beginning of section 5 apply only to those rules. This means they apply only to type declaration statements. Since a derived type component is part of a derived type definition (which is not a type declaration statement), the constraints do not apply to derived type components. The rule that prevents an entity from having conflicting attributes when applied by multiple specification statements is found in 5.2: "The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification." The sentence from 6.1.2 cited in the question is not necessary (and is thus deleted by an edit) because the "barrier" to a reference or definition of a structure component is at the structure (parent) level and thus no additional "barrier" is needed at the component level. Thus, for example, specifying an attribute such as TARGET at the structure level is sufficient; there is no need to "trickle down" the attribute to components of the structure (and indeed if a component were treated as an independent variable, the combination of TARGET and POINTER would otherwise be prohibited). The philosophy that an attribute applied at the structure (parent) level is all that is needed is borne out by the following: TARGET: Section 7.5.2, second constraint states: "The must have the TARGET attribute or be a subobject of an object with the TARGET attribute ..." PARAMETER: Rule R601 and the constraints associated with it state that neither an nor a can have the PARAMETER attribute and that a must not be a subobject designator whose parent is a constant. INTENT(IN): The response to defect item 135 added a constraint to 5.1.2.3 that states that a dummy argument with the INTENT(IN) attribute, or a subobject of such an object, must not appear in any assignment context. EDIT: In section 6.1.2, in the paragraph following the last constraint [63:15-17], delete the sentence that starts: "A structure component has the INTENT..." SUBMITTED BY: J. Martin in response to email May 7, 1993 from Yukimasa Yoshida HISTORY: 93-179 m125 canceled, interpretation number then reassigned 93-181 m125 Response, Withdrawn to remove suggested edit. 93-223r m126 Response proposed, approved uc 93-255r1 m127 ballot failed 18-5 94-339 m131 Revised response proposed, approved 14-2 95-034r1 m132 X3J3 ballot failed 8-12 95-033 m132 Revised response, straw vote on intent 5-2-7 95-092 m132 Revised discussion, approved u.c. 95-101 m133 X3J3 ballot failed 11-7 -------------------------------------------------------------------------------- NUMBER: 000145 TITLE: Expressions in of a FUNCTION statement KEYWORDS: expression - specification, expression - initialization, FUNCTION statement, host association, use association DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: The syntax rule R1217 shows that the type and type parameters of a function can be specified in the FUNCTION statement (12.5.2.2). (a) If a appears in a FUNCTION statement, can the initialization and specification expressions of that involve names of entities that are declared within the function or are accessible there by host or use association? (b) Section 5.1 states: "The (7.1.6.2) of a (5.1.1.5) or an (5.1.2.4) may be a nonconstant expression provided the specification expression is in an interface body (12.3.2.1) or in the specification part of a subprogram." As a FUNCTION statement is not part of the specification part of a subprogram, this text in the standard appears to distinguish between FUNCTION statements that are in interface blocks and ones that are not. This text seems to prohibit such examples as: INTEGER I ... CONTAINS CHARACTER*(I+1) FUNCTION F() ... COMMON // I ... where it can be confusing as to which I is being referenced in the FUNCTION statement. While host association does not apply to interface bodies, for consistency should the text quoted from Section 5.1 have been "... is in the specification part of an interface body (12.3.2.1) or in the specification part of a subprogram."? (c) Section 7.1.6.1 states: "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." Was this text intended to apply to FUNCTION statements even though they are not part of any , thus disallowing fragments such as: INTEGER (KIND=KIND(X)) FUNCTION F() INTEGER(KIND=KIND(0)) X ... Similar text appears in Section 7.1.6.2. ANSWER: (a) A specification expression in the of a FUNCTION statement may involve names of entities that are declared within the function or are accessible there by host or use association, but an initialization expression in such a may only involve names that are accessible by host or use association. (b) No. It was not the intent of the standard to distinguish between the two types of FUNCTION statements cited. As elaborated in the discussion of part (a), the standard intended to allow the expression of a FUNCTION statement to be a nonconstant expression. The sentence cited is corrected with a supplied edit. (c) Yes, the text cited from 7.1.6.1 was intended to apply to FUNCTION statements. The sentence quoted and the corresponding sentence in 7.1.6.2 are corrected with supplied edits. The code fragment is not standard conforming. Discussion: (a) An initialization expression is a constant expression with an additional rule relating to exponentiation (7.1.6.1). Since it is a constant expression, the only names it can contain are the names of named constants, structure constructors, intrinsic procedures, and variables whose type parameters or bounds are inquired about. * Named constant Section 5.1.2.1 states: "A named constant must not be referenced in any ... context unless it has been defined in a prior PARAMETER statement or type declaration statement using the PARAMETER attribute, or made accessible by use association or host association." Since the FUNCTION statement is the first statement of the scoping unit, there can be no prior PARAMETER statement or type declaration statement using the PARAMETER attribute, so the first clause does not apply. A named constant can appear in a of a function statement if it is accessible within the function by host or use association. * Structure constructor Rule R502 shows that the only opportunities for expressions to appear in s are in a or in a . However, a structure constructor can not appear in a because rule R505 shows that a must be an integer expression. Similarly, R506 shows that any initialization expression in a must be type integer. Therefore, a structure constructor can not appear in an initialization expression in the of a FUNCTION statement. * Intrinsic procedure The intrinsic procedure names or classes of intrinsic procedures that may appear in an initialization expression are given in 7.1.6.1. * Variables whose type parameters or bounds are inquired about The text from section 7.1.6.1 as cited in question (c) was intended to apply to initialization expressions in the of a FUNCTION statement. With the correction supplied, this means that if a variable appears as the argument to an inquiry intrinsic in the of a FUNCTION statement, the function must be a module procedure or an internal procedure, and the variable must exist in (be accessible from) the host scoping unit. Rule R502 defines . The only opportunity for a to contain a is when the data type is character ( may be a ). Section 7.1.6.2 states that a specification expression is a restricted expression that is scalar, of type integer, and each operation must be intrinsic. In addition, rule (2) of 7.1.6.2 states that a primary of a specification expression can be a dummy argument that has neither the OPTIONAL nor INTENT(OUT) attribute. The following code fragment demonstrates a use of such a dummy argument: CHARACTER*(N+1) FUNCTION S(N) INTEGER, INTENT(IN) :: N Rule (2) also states that the primary can be a subobject of such a dummy argument. Section 6.1.2 indicates that a structure component must not be referenced or defined before the declaration of the parent object. Similar rules are needed to prevent a substring from being referenced ahead of the declaration of its parent, and an array element or array section from being referenced ahead of the declaration of the array. Edits are provided to supply these rules. Since a subobject can not be referenced before its parent object is declared and the FUNCTION statement is the first statement of the subprogram, the parent's declaration could not have occurred. Thus a subobject must not be referenced in the on a FUNCTION statement for objects declared within the function. Rule (3) states that a primary can be a variable that is in a common block. The following code fragment demonstrates a use of such a common block member: CHARACTER*(N+1) FUNCTION S() ... COMMON N As in rule (2), rule (3) allows a subobject of such a variable but for the same reasons as above, such a subobject designator can not appear in the expression of a FUNCTION statement. Rule (4) states that a primary may be a variable that is accessible by use association or host association. The following code fragments demonstrate uses of such variables: PROGRAM MAIN INTEGER :: N = 21 ... CONTAINS CHARACTER(LEN = 2*N) FUNCTION SS(K) ! N is host associated. ... END FUNCTION END PROGRAM and MODULE MOD INTEGER K DATA K /20/ END MODULE CHARACTER*(K*2) FUNCTION CHECK(STR) ! K is use associated. USE MOD ... END FUNCTION Rule (4) also states that the primary can be a subobject of such a use or host associated variable. A structure constructor can not appear in a FUNCTION specification expression because the expression must be of type integer and any operations (which might yield an integer value from one or more structure constructors) must be intrinsic. Other rules of 7.1.6.2 state which intrinsic procedure names or classes of intrinsic procedures may appear in a specification expression. Section 7.1.6.2 also states: A variable in a specification expression must have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit type rules currently in effect for the scoping unit, or by host or use association. The discussion above regarding specification expressions has already ruled out "previous declarations" so the first clause of the cited sentence does not apply. The other clauses apply equally to a FUNCTION statement and to type declaration statements inside the function. (b) When the discussion for part (a) is applied to the code fragment provided, it means that the 'I' referenced in the of the FUNCTION statement is the common block member. EDITS: 1. Section 5.1, in the first sentence of the paragraph that starts "The (7.1.6.2)" [40:39-41], change "in an interface body (12.3.2.1) or in the specification part of a subprogram" to "contained in an interface body (12.3.2.1), is contained in the specification part of a subprogram, or is in the of a FUNCTION statement (12.5.2.2)" 2. Section 6.1.1, add to the end of the paragraph before the examples [62:29] "A substring must not be referenced or defined before the declaration of the type and type parameters of the parent string, unless the type and type parameters are determined by the implicit typing rules of the scope." 3. Section 6.2.2, add after the sentence "An array section is an array." [64:16] "An array element or array section must not be referenced or defined before the declaration of the array bounds." 4. Section 7.1.6.1, in the paragraph after the constraints [78:21-22] change "object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "object declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the initialization expression." 5. Section 7.1.6.2, in the 2nd paragraph after the constraint [79:28-29] change "entity specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "entity declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the specification expression." SUBMITTED BY: Janice C. Shepherd HISTORY: 93-193 m126 submitted 94-023r1 m128 response, approved uc 94-116r1 m129 X3J3 ballot failed 22-1 94-336 m131 revised response, approved u.c 95-034r1 m132 X3J3 ballot failed 15-5 95-281 m135 revised response, reworded edit 3, WG5 approved (N1161) 96- m136 X3J3 ballot failed 15-1, WG5 approval removed. -------------------------------------------------------------------------------- NUMBER: 000164 TITLE: Use of ONLY with multipart definitions KEYWORDS: ONLY, module, derived type DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Sections 11.3.1 and 11.3.2, among others, describe how accessibility of data objects, derived type definitions, etc. can be controlled via the ONLY clause of the USE statement and via the PUBLIC and PRIVATE accessibility attributes/statements. But these sections do not describe what happens when a definition consists of multiple parts and only some of the parts have their accessibility controlled. Examples include, but are not limited, to the following: Example 1: MODULE MOD INTEGER, PARAMETER :: MAX_SIZE = 100 INTEGER, DIMENSION(MAX_SIZE) :: ARRAY END MODULE PROGRAM MAIN USE MOD, ONLY: ARRAY ... END PROGRAM Since the declaration of ARRAY depends on the value of MAX_SIZE, is it valid to only allow access to ARRAY? Is the array constructor for ARRAY, for example, accessible to the main program? Example 2: MODULE MOD TYPE INNER INTEGER I END TYPE TYPE OUTER INTEGER K TYPE(INNER) COMP END TYPE END MODULE PROGRAM MAIN USE MOD, ONLY: OUTER ... END MODULE The derived type OUTER in module MOD has a component of derived type INNER. However, when the main program accesses the module, it restricts access to only derived type OUTER. Since OUTER depends on the definition of INNER, is it valid to only allow access to OUTER? If it is not valid, is it only an error if something in the main program actually tries to use OUTER? Can you write a structure constructor for OUTER in the main program? If it is valid, can component I of substructure COMP be referenced? Example 3: MODULE MOD TYPE DEF INTEGER K REAL R END TYPE TYPE(DEF) VAR END MODULE PROGRAM MAIN USE MOD, ONLY: VAR ... END MODULE In this example, only the variable VAR from the module is accessible; its type is not. Is this valid? If it is valid, can only the structure name VAR be referenced or can its components also be referenced? If only the structure name VAR can be referenced, what is the meaning when the structure name is included in a namelist object list for input and/or output? Example 4: MODULE MOD INTEGER, PARAMETER :: MAX_SIZE = 100 INTEGER, DIMENSION(MAX_SIZE) :: ARRAY PRIVATE MAX_SIZE END MODULE PROGRAM MAIN USE MOD ... END PROGRAM Another way to limit access to items in modules is via the PRIVATE attribute/statement. Since the declaration of ARRAY depends on the value of MAX_SIZE, is it valid to only allow access to ARRAY? Is the array constructor for ARRAY, for example, accessible to the main program? ANSWER: EDIT(S): SUBMITTED BY: Larry Rolison HISTORY: 94-038 m128 submitted -------------------------------------------------------------------------------- NUMBER: 000179 TITLE: DO variable with POINTER attribute KEYWORDS: DO variable, POINTER attribute DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: The first constraint following rule R822 states: "Constraint: The must be a named scalar variable of type integer, default real, or double precision real." The definition of loop initiation (8.1.4.4.1) states: "(2) The DO variable becomes defined with the value of the initial parameter 1." The definition of the execution cycle of a DO loop (8.1.4.4.2) states: "(3) ... The DO variable, if any, is incremented by the value of the incrementation parameter 3." Consider the following program: INTEGER, POINTER :: PTR INTEGER, TARGET :: LCV PTR => LCV DO PTR = 1, 3 PRINT *, LCV END DO END Note that the DO variable has the POINTER attribute. The POINTER attribute does not seem to be prohibited for the DO variable, but when the DO variable has the POINTER attribute, it is unclear as to whether the DO variable is the pointer or the target of the pointer. That is, it is unclear as to whether the pointer or the target is to be "defined" (8.1.4.4.1) or incremented (8.1.4.4.2). Also consider the following modification of the above program: INTEGER, POINTER :: PTR INTEGER, TARGET :: LCV1, LCV2 LCV1 = 1 LCV2 = 4 PTR => LCV1 DO PTR = 1, 3 IF (...) PTR => LCV2 ! An alternate EXIT form? END DO END The standard does not seem to address what happens when the DO variable is switched to a different variable while the loop is active. Is it the intent of the standard to permit a DO variable with the POINTER attribute? ANSWER: Yes, a DO variable may have the POINTER attribute. Discussion: There are a number of contexts in the language where the target of a pointer is referenced or defined when it is the pointer name that appears. Two of these are cited in items (2) and (3) in the Question. In (2), the target of the pointer variable is defined with the value of the DO loop initial value parameter. In (3), the target of the pointer variable is incremented. Other examples of these kinds of contexts are: * Section 6.3.1, which describes the ALLOCATE statement: "If the STAT= specifier is present, successful execution of the ALLOCATE statement causes the to become defined with a value of zero." * Section 9.4.1.5, which describes the semantics of the I/O error branch: "(2) If the input/output statement also contains an IOSTAT= specifier, the variable specified becomes defined with a processor-dependent positive integer value," In contexts such as these, the variable involved may have the POINTER attribute and it is the intent of the standard that it is the target of the pointer that is being defined, incremented, etc. With respect to the modified example in the Question, the standard does address what happens when the DO variable appears on the left hand side of a pointer assignment. In the modified example in the Question, the statement IF (...) PRT => LCV2 ! An alternate EXIT form? is prohibited. Section 14.7.6 states: "(18) Execution of a pointer assignment statement that associates a pointer with a target that is defined causes the pointer to become defined." but section 8.1.4.4.2 states: "Except for the incrementation of the DO variable that occurs [when the DO variable is incremented by the value of the incrementation parameter], the DO variable must neither be redefined nor become undefined while the DO construct is active." Thus, since the pointer assignment statement causes the DO variable to become (re)defined, it is prohibited. Similarly, if the modified example had contained within the DO construct an assignment statement such as: PRT = 10 such an assignment statement would also be prohibited because defining the target of a pointer also defines the pointer as stated in section 14.6.2.2: "The definition status of a pointer is that of its target." EDITS: None. SUBMITTED BY: Larry Rolison HISTORY: 94-226r1 m130 submitted, approved 10-1 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot, failed see Cohen's comments 95-246 m134 revised edits, approved u.c. 95-256 m135 X3J3 ballot, failed 10-6 95-304r1 m135 revised response, delete edits, approved u.c. 96- m136 X3J3 ballot, approved 15-1 -------------------------------------------------------------------------------- NUMBER: 000180 TITLE: Unambiguous generic references KEYWORDS: host association, generic name DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Consider the following example: SUBROUTINE S() INTERFACE GEN1 FUNCTION F1(I) END FUNCTION FUNCTION F2(I,J) END FUNCTION END INTERFACE INTERFACE GEN2 FUNCTION G1() END FUNCTION FUNCTION G2(I) END FUNCTION END INTERFACE CALL SS() CONTAINS SUBROUTINE SS() INTERFACE GEN1 FUNCTION F3(I,J,K) END FUNCTION FUNCTION F4(II) END FUNCTION END INTERFACE INTERFACE GEN2 SUBROUTINE G3() END SUBROUTINE END INTERFACE A = GEN1(1,2,3) ! CALL TO F3 A = GEN1(1,2) ! CALL TO F2 A = GEN1(1) ! CALL TO F4 CALL GEN2() ! CALL TO G3 END SUBROUTINE END There are rules in section 14.1.2.3 that determine within a scoping unit what procedures can have the same generic specification. These rules directly mention access of a generic procedure via use association, but they make no mention of generic names accessed via host association. There is evidence that the rules in section 14.1.2.3 were not intended to apply to generic interfaces accessed by host association. Section 14.1.2.4.1 indicates that a call to a generic name can be resolved to a generic name in the host if the scoping unit and the host scoping unit both agree that the generic name is the name of a function or a subroutine. This indicates that in the example above, the definition of 'GEN2' is valid, even though 'G1' and 'G2' are functions while 'G3' is a subroutine. If the rules set out in 14.1.2.3 were to apply then the definition of 'GEN2' would be invalid. Do the rules in 14.1.2.3 apply to generic procedures accessed via host association? ANSWER: No. The rules in 14.1.2.3 were intended to apply to only those specific procedures declared to be generic in a scoping unit and those accessed via use association. Edits are included to clarify this. EDITS: 1. Add to the end of the first sentence of section 14.1.2.3 [242:27] "when the generic interfaces for each of the specific procedures are declared in the same scoping unit or accessed via use association." 2. Add to the end of the first paragraph of section 14.1.2.3 [242:32] "When a generic procedure is accessed from a host scoping unit, the steps for resolving a procedure reference as described in 14.1.2.4.1 have the same effect as if the rules restricted which specific versions from the host scoping unit can be accessed via the generic reference." SUBMITTED BY: Janice C. Shepherd HISTORY: 94-239r3 m130 submitted with suggested answer, approved u.c. 94-306 m131 X3J3 ballot, failed 15-4 -------------------------------------------------------------------------------- NUMBER: 000185 TITLE: What is the allocation status of an array after an allocation failure? KEYWORDS: ALLOCATE, POINTER, DEALLOCATE, status DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: It does not appear that the standard defines the allocation status of an array if an ALLOCATE statement fails and returns a nonzero STAT= value? Given a program segment such as: REAL, ALLOCATABLE, DIMENSION(:) :: A,B,C ALLOCATE(A(10), B(10), C(10), STAT = ISTAT) Question 1: If "ISTAT" comes back non-zero, is it legal to deallocate the arrays and try to reallocate them with smaller sizes? Question 2: If instead of allocatable arrays, the variables had been pointers, is it legal to NULLIFY them? Question 3: Are the answers to questions 1 and 2 different if a single array is allocated rather than a list? Question 4: If a DEALLOCATE fails for a list, what is the allocation status of the arrays? Question 5: Is it acceptable to use the ALLOCATED and/or ASSOCIATED functions to attempt to recover from a failure? Question 6: 6.3.1.1 might be read to mean that successful allocation makes the arrays "currently allocated" and otherwise leaves them "not currently allocated". But that's not an obvious reading of the text. In some ways I/O is similar to allocate (they both process a list of things and have a STAT= clause). If an input statement fails then everything in the list becomes undefined. Does that apply by analogy to ALLOCATE? ANSWER 1: Yes. Note that one or more of the arrays is expected to have an allocation status of "currently not allocated", due to the error which occurred. See the Discussion below. Note that this example only used allocatable arrays. If a pointer appears in a DEALLOCATE statement, its pointer association status must be defined (section 6.3.3.2). See the Discussion below. ANSWER 2: Yes. See section 14.6.2.3. ANSWER 3: No, the answers are the same. See Answer 6 below. ANSWER 4: When a DEALLOCATE with a "STAT=" specifier fails, those arrays that were successfully deallocated will have an allocation status of deallocated. Those arrays not successfully deallocated retain their previous allocation status. ANSWER 5: For ALLOCATED, yes. For ASSOCIATED, it depends on the pointer association status of the pointer at the time the ASSOCIATED intrinsic is called. The ALLOCATED intrinsic may be called with any allocatable array whose allocation status is either currently allocated or currently not allocated. The ASSOCIATED intrinsic must not be called with a pointer whose pointer association status is undefined (section 6.3.3.2). See the Discussion below. ANSWER 6: No. The standard does not require a processor to allocate the variables specified in an ALLOCATE statement as a group; therefore, a processor may successfully allocate some of the arrays specified in an ALLOCATE statement even when that ALLOCATE statement assigned a positive value to the variable specified in the STAT= specifier. Discussion: Only when the allocation status of an array is undefined is it illegal to specify the array in a DEALLOCATE statement. The only way for an allocatable array to have a status of undefined is described in section 14.8, item (3). If an array specified in a DEALLOCATE statement has an allocation status of not currently allocated when the DEALLOCATE statement is executed, an error condition occurs as described in section 6.3.3.1. The behavior of the DEALLOCATE statement in the presence of an error condition is described in section 6.3.3. Immediately after the execution of an ALLOCATE statement, all allocatable arrays specified in that ALLOCATE statement will have a defined allocation status. The arrays that were successfully allocated will have an allocation status of allocated, while any arrays not successfully allocated will retain their previous allocation status. When a pointer is specified in an ALLOCATE statement which fails (assigns a positive value to ISTAT in this example), then the pointer association status of that pointer will not be changed if the allocation failed for that particular pointer. If that pointer previously had a pointer association status of undefined, it will still have a pointer association status of undefined immediately after the ALLOCATE statement is executed; therefore, it would be illegal to specify that pointer in a DEALLOCATE statement (section 6.3.3.2) or in a call to the ASSOCIATED intrinsic (section 13.13.13), unless the allocation status of the pointer was first changed to be defined (either associated or disassociated). EDITS: None. SUBMITTED BY: Dick Hendrickson HISTORY: 94-296 m131 submitted 95-039 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot approved, 12-6 95-310r1 m135 revised response to be consistent with F95, approved u.c. 96- m136 X3J3 ballot approved, 15-1 -------------------------------------------------------------------------------- NUMBER: 000190 TITLE: Subobjects of constants in a DATA statement KEYWORDS: DATA stmt, constant DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Consider the following syntax rules from Section 5.2.9: R532 is [*] R533 is ... R534 is and the following constraint Constraint: A of a must involve as primaries only constants or DO variables of the containing s, and each operation must be intrinsic. In all cases, the rules reduce to "constant". The definition of "constant" is provided by R305: R305 is or R307 is The above two rules seem to indicate that if an identifier appears where "constant" is allowed in the DATA statement rules cited above, the identifier must be a name; that is, it can not be the subobject of a named constant. Is this analysis correct? ANSWER: Yes, your analysis is correct. A , a , and a constant appearing in a of a DATA implied-DO can be a name (of a named constant) but not a subobject designator. Discussion: There is no intent in the standard to extend the above rules over what was provided in the FORTRAN 77 standard. So, for example, the following program fragment is not standard conforming: INTEGER, PARAMETER :: PARR(3) = (/ 1, 2, 3 /) INTEGER :: ARRAY(3) DATA (ARRAY(I), I = PARR(1), 3) / PARR(1), PARR(2)*PARR(3) / EDITS: None SUBMITTED BY: Larry Rolison HISTORY: 94-302 m131 submitted, with proposed response 94-360 m131 alternate answer proposed, failed 7-7 94-302 m131 original answer, approved 14-2 95-034 m132 X3J3 ballot failed 15-5 -------------------------------------------------------------------------------- NUMBER: 000191 TITLE: Interaction of SEQUENCE derived types and rename KEYWORDS: SEQUENCE, derived type, use association, derived type DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Consider the following: MODULE M TYPE T SEQUENCE TYPE (T), POINTER :: P END TYPE END MODULE USE M, T2=>T TYPE T SEQUENCE TYPE (T2), POINTER :: P END TYPE TYPE (T) X TYPE (T2) Y X = Y END Section 4.4.2, 'Determination of derived types', seems to indicate that types T and T2 in the main program refer to the same type. Note that both types have structure components that agree in order, name, and attributes. However, considering type T in the context of module M only, type T is a derived type that contains one component that is a pointer to itself. In the context of the main program, type T is a derived type that contains one component that is a pointer to a different derived type. Are types T and T2 considered to be the same type? ANSWER: Yes, T and T2 are the same type. An edit is provided to clarify this conclusion. Discussion: The first sentence in section 4.4.2 states, "a particular type name may be defined at once in a scoping unit." However, by the use of rename, it's possible for a scoping to have access to two separately defined derived types, that were originally defined the same name, by two different local names. For derived types made accessible by use association, the derived type name referred to in section 4.4.2 is in the corresponding . Edits are provided to clarify this. EDITS: 1. In section 4.4.2, add the following to the end of the first paragraph: [35:39] "In addition, two derived types accessible in the same scope might be the same if one or both are accessible by use association." 2. In section 4.4.2, after the second paragraph, add the following independent paragraph: [35:46] "Note that the criterion that the two types have the same name applies to the of the respective ." SUBMITTED BY: Janice C. Shepherd HISTORY: 94-273 m130 submitted 94-377 m131 Response submitted, approved u.c. 95-034r1 m132 X3J3 ballot failed 15-5 -------------------------------------------------------------------------------- NUMBER: 000194 TITLE: Statements between SELECT CASE and CASE KEYWORDS: FORMAT statement, DATA statement, SELECT CASE statement, CASE statement, INCLUDE line, statement order DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: 1. Figure 2.1 (page 11) shows that FORMAT and DATA statements may be intermixed with executable constructs but it is not clear at what points within an executable construct these statements may appear. In particular, may FORMAT and DATA statements appear between the SELECT CASE statement and the first CASE statement of a CASE construct? 2. May an INCLUDE line appear between the SELECT CASE statement and the first CASE statement of a CASE construct? ANSWER: 1. No. In general, FORMAT and DATA statements may appear in the IF, CASE and DO executable constructs because these constructs contain blocks and a block is defined in section 8.1 (on page 95) to consist of s, which in turn are defined as being made up of FORMAT and DATA statements, among others. However, the syntax rules for the CASE construct do not provide for any blocks or any other statements to appear between the SELECT CASE statement and the first CASE statement of a CASE construct. The sentence in 8.1 [95:12] that defines a block in prose introduces the general concept of a block, and does not precisely define the BNF term. The BNF syntax rules give the precise definition. 2. Yes. An INCLUDE line may appear between a SELECT CASE statement and the first CASE statement of a CASE construct because an INCLUDE line is a line, not a statement. EDITS: None. SUBMITTED BY: Larry Rolison HISTORY: 94-383r1 m131 submitted with proposed response, approved 13-3 95-034r1 m132 X3J3 ballot approved 19-1, with edits 95-116 m133 (N1112) correct typo in answer 2. 95-305r1 m135 changed to match F95 approved edits, approved u.c. 96- m136 X3J3 ballot approved 16-0 -------------------------------------------------------------------------------- NUMBER: 000196 TITLE: Inaccessibility of intrinsic procedures KEYWORDS: intrinsic procedure, INTRINSIC attribute, generic identifier, names class DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 14.1.2 states: "Note that an intrinsic procedure is inaccessible in a scoping unit containing another local entity of the same class and having the same name. For example, in the program fragment SUBROUTINE SUB ... A = SIN (K) ... CONTAINS FUNCTION SIN(X) ... END FUNCTION SIN END SUBROUTINE SUB any reference to function SIN in subroutine SUB refers to the internal function SIN, not to the intrinsic function of the same name." Are the following two comments about this text correct? (1) The example is not strictly correct because the resolution of the procedure reference "SIN" depends on the contents of the first "...": (1a) If "..." does not contain an "INTRINSIC SIN" statement, the behavior is as specified: In SUB, the name SIN is established specific due to condition 14.1.2.4 part (2b), it is not established generic, and the internal function SIN is referenced due to 14.1.2.4.2 part (3). (1b) If "..." does contain an "INTRINSIC SIN" statement, SIN is established specific as above, but also established generic due to condition 14.1.2.4 (1b). So the reference is resolved according to 14.1.2.4.1 part (2): the intrinsic function SIN is called. ( At least if there is a suitable specific function for data ) ( object K. If not, the reference is resolved according to ) ( 14.1.2.4.1 (4) which also requires a consistent reference. ) (2) The first sentence of the cited text is wrong (incomplete), because it does not consider the case of generic identifiers: * Intrinsic procedures are local entities of class (1). * Generic identifiers are local entities of class (1). * Various instances in the standard indicate that it is possible to extend the generic interface of intrinsic procedures. Consequently, in the example MODULE my_sin CONTAINS LOGICAL FUNCTION lsin (x) LOGICAL, INTENT(IN) :: x ... END FUNCTION lsin END MODULE my_sin SUBROUTINE sub USE my_sin INTERFACE SIN MODULE PROCEDURE lsin END INTERFACE SIN ... END SUBROUTINE sub the intrinsic procedure SIN remains accessible in SUB although that scoping unit contains another local entity of class (1) named SIN. ANSWER: Comment 1 is incorrect. See the answer to (1b). Comment 1a is correct. Comment 1b is incorrect. SIN is a local name for the internal procedure, which is a specific procedure, and adding an "INTRINSIC SIN" statement is prohibited by 14.1.2, 3rd paragraph. Comment 2 is correct. Edits to remove the contradiction are included below. EDITS: 1.In section 14.1.2, 4th paragraph [241:36], change "having the same name" in the first sentence to "having the same name, except when the other local entity and the intrinsic are both generic procedures" 2.In Section 14.1.2, 3rd paragraph [241:33], change "in the case of" to "when both are" SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: 95-252 m135 submitted 95-281 m135 response WG5 approved (N1161) 96- m136 X3J3 ballot failed 16-0, possible error in 2nd edit, WG5 approval removed. Barber edit applied -------------------------------------------------------------------------------- NUMBER: 000197 TITLE: Relationship of NEAREST and SPACING KEYWORDS: NEAREST, SPACING, "machine representable" DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: The example in the SPACING intrinsic function description states: SPACING(3.0) has the value 2**(-22) for reals whose model is as at the end of 13.7.1. The example in the NEAREST intrinsic function description states: NEAREST(3.0, 2.0) has the value 3 + 2**(-22) on a machine whose representation is that of the model at the end of 13.7.1. Must the delta computed by NEAREST (the 2**(-22) shown in the example) be the value SPACING would return if given the same (first) argument as passed to NEAREST? ANSWER: Discussion: EDIT(S): SUBMITTED BY: Larry Rolison HISTORY: 95-030 m132 submitted -------------------------------------------------------------------------------- NUMBER: 000200 TITLE: subsumed by 000202: Evaluation of NINT and machine approximations KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: Is the expression INT(A + 0.5) in the description of NINT meant to be evaluated exactly or as a machine approximation? This request for interpretation is the result of having discovered that a Fortran 90 compiler produces the value 16,000,002 for the expression NINT(16 000 001 . 0). At first glance, this appeared to be a bug; however, the algorithm used to implement NINT in this compiler is the algorithm from the Fortran 90 standard. That algorithm computes the NINT of a value A that is greater than zero as INT(A + 0.5). When A is 16,000,001.0, the value of A + 0.5 (in single=precision) is 16,000,002.0 on some machines. ANSWER: See defect 000202. EDITS: None. SUBMITTED BY: Robert Corbett HISTORY: 95-182 m134 submitted 95-247r1 m134 approved as the response to NUMBER 000202 subsumed by 000202 -------------------------------------------------------------------------------- NUMBER: 000202 TITLE: Evaluation of intrinsic procedures KEYWORDS: algorithm, mathematical, computational DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: When the standard specifies an algorithm for computing a mathematical procedure, must a processor use that algorithm? For example, ANINT is defined as INT(A+0.5). On some processors ANINT(16 000 001.0) evaluates to 16 000 002.0 using this algorithm; but if it can be computed as the more expected 16 000 001.0, may a processor do so? See, also, item 000200 which this item subsumes. ANSWER: No, a processor is not bound to use the algorithm from the standard. Yes, a processor may return the mathematically equivalent result for ANINT. Discussion: The standard is intended to permit processors to use infinite accuracy if available. It is also intended to allow processors to use any mathematically equivalent algorithm the processor desires. EDITS: None SUBMITTED BY: Keith Bierman HISTORY: 95-247r1 m134 submitted with proposed response, approved 9-4 subsumes defect item 200 95-256 m135 X3J3 ballot failed 10-6 95-260 m135 alternate answer (text here is still 95-247r1) ------------------------------------------------------------------------------- NUMBER: 000204 TITLE: Meaning of "same variable" description of MVBITS KEYWORDS: MVBITS DEFECT TYPE: STATUS:X3J3 consideration in progress QUESTION: Section 13.13.74 states "TO ... may be the same variable as FROM". Given the following statements, which pairs of variables are the same? INTEGER :: I(10), J(10) EQUIVALENCE (I,J) INTEGER, TARGET :: T(2:11) INTEGER, POINTER :: P1(:), P2(:) P1 => T P2 => T(2:11) I and I P1 and T I(1) and I(1) P1 and T(2:11) I(1:10) and I(1:10) P2 and T I(1:1) and I(1:1:-1) P2 and T(2:11) I and I(1:10) P1 and P2 I and J I(1) and J(1) I(1:10) and J(1:10) I(1:1) and J(1:1:-1) I and J(1:10) ANSWER: Discussion: EDITS: SUBMITTED BY: /jor in response to IBM public comments HISTORY: 95-299 m135 submitted ------------------------------------------------------------------------------- NUMBER: 000205 TITLE: Restrictions on EXTERNAL KEYWORDS: EXTERNAL attribute, external subprogram DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Let the following two procedures not be contained within a main program, a module, or another subprogram. In this case they are <>s by the definitions of Fortran 90, section 2.2: SUBROUTINE subroutine_subprogram ( ) ! ... END SUBROUTINE subroutine_subprogram FUNCTION function_subprogram ( ) INTEGER :: function_subprogram ! ... END FUNCTION function_subprogram They are also external procedures, since F90 section 2.2.3.1 (and 12.1.2.2) states that "An <> is a procedure that is defined by an external subprogram or by means other than Fortran." External functions may be given the EXTERNAL attribute in form of an (R503), external procedures may be given the EXTERNAL attribute by an (R1207) [F95: R1208]. QUESTION 1: Is it correct that the current definitions in F90 do allow the EXTERNAL attribute to be specified for the name of the external subprogram in which such a declaration is contained? In other words, is the following code standard-conforming? SUBROUTINE subroutine_subprogram ( ) EXTERNAL subroutine_subprogram ! ... END SUBROUTINE subroutine_subprogram FUNCTION function_subprogram ( ) INTEGER, EXTERNAL :: function_subprogram ! ... END FUNCTION function_subprogram QUESTION 2: If the answer to question 1 is YES: was this the intention, or should it be prohibited that an EXTERNAL attribute is given to the name of an external subprogram by declarations within that subprogram? ANSWER: EDIT: SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: 96- m136 submitted ------------------------------------------------------------------------------- NUMBER: 000206 TITLE: Collating sequence inconsistencies KEYWORDS: Collating sequence, ACHAR, CHAR, ICHAR DEFECT TYPE: STATUS: X3J3 consideration in progress [F95 CD 36:28+] says that "A <> is a one-to-one mapping of the characters into the nonnegative integers such that each character corresponds to a different nonnegative integer." QUESTION 1: Does this definition imply that the one-to-one mapping is dense? That is, is there a requirement that if the default CHARACTER type has characters, the corresponding collationg sequence maps to 0..-1 ? QUESTION 2: If the answer to question 1 is NO: is it correct that the restriction 0 <= i <= -1 on argument I of the intrinsic procedure CHAR (13.14.19) is inappropriate? QUESTION 3: If the answer to question 1 is NO: is it correct that the description of the <> of the intrinsic procedure ICHAR (13.14.45), 0 <= ICHAR(C) <= -1 is inappropriate? QUESTION 4: Shouldn't argument I of the intrinsic procedure ACHAR (13.14.2) be restricted to the nonnegative integers? ANSWER: EDIT: SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: submitted Feb. 17, 1996 (first appeared in 96-006r2) ------------------------------------------------------------------------------- NUMBER: 000207 TITLE: Integer bit-model inconsistency KEYWORDS: Bit manipulation procedures, models for integer data DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Is the following observation true? [F90 185:last scentence of 13.5.7] and [WG5/N1176, 219:22+] says ``In particular, whereas the models are identical for w_{z-1}=0, they do not correspond for w_{z-1}=1 and ...'' This statement assumes r==2 in the model for integer data defined in 13.7.1, it is not true for general r. The above sentence should be changed to something like ``In particular, whereas the models are identical for r=2 and w_{z-1}=0, they do not correspond for r/=2 or w_{z-1}=1, and ...'' ANSWER: EDIT: SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: submitted Mar. 12, 1996 (first appeared in 96-006r2) ------------------------------------------------------------------------------- NUMBER: 000208 TITLE: nonadvancing output followed by list directed output KEYWORDS: DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Section 10.8.2, last sentence. If nonadvancing output is followed by list-directed output, is a blank required before the first character written? (I assume that if the first character of the current record is not a blank, list-directed output is not required, though possibly permitted, to replace that character with a blank.) ANSWER: EDIT: SUBMITTED BY: Robert Paul Corbett (robert.corbett@Eng.sun.com) HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) ------------------------------------------------------------------------------- NUMBER: 000209 TITLE: STOP|PAUSE in I/O statement KEYWORDS: DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Section 9.7. May a function referenced in an I/O statement execute a STOP or PAUSE statement? If STOP statements are permitted, what is the state of the file at the end of execution? ANSWER: EDIT: SUBMITTED BY: Robert Paul Corbett (robert.corbett@Eng.sun.com) HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) ------------------------------------------------------------------------------- NUMBER: 000210 TITLE: nonadvancing write followed by list directed write KEYWORDS: DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: If a program does a nonadvancing WRITE followed by a list-directed WRITE, must the list-directed WRITE write to the current record or may it start a new record? For what it's worth, CRI f90 starts a new record. ANSWER: EDIT: SUBMITTED BY: Robert Paul Corbett (robert.corbett@Eng.sun.com) HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) ------------------------------------------------------------------------------- NUMBER: 000211 TITLE: Multiple MODULE PROCEDURE specs KEYWORDS: MODULE PROCEDURE, generic interface, USE association DEFECT TYPE: STATUS: X3J3 consideration in progress WG5/N1176 (X3J3/96-007) says [194:21-23]: "Constraint: A in a shall not be one which previously had been specified in any with the same generic identifier in the same specification part." QUESTION: 1. Is it correct that this constraint does not preclude the following? MODULE foo1 INTERFACE generic_spec MODULE PROCEDURE proc1 END INTERFACE CONTAINS SUBROUTINE proc1 END SUBROUTINE proc1 END MODULE foo1 MODULE foo2 USE foo1 INTERFACE generic_spec MODULE PROCEDURE proc1 END INTERFACE END MODULE foo2 Although foo2 clearly violates the uniqueness conditions in 14.1.2.3, it seems that it does not violate a Constraint. (Actual compilers do not seem to detect this form of violation of 14.1.2.3 at compile-time.) 2. If the answer to (1) is YES, wouldn't it be sensible to extend that constraint to cases where a "previous" specification of in a with the same generic identifier in the specification part of an accessible module had occured, _and_ that and generic-spec have PUBLIC accessibility? Probably the wording might be quite complicated because of the possibility of s if FOO1 and s in FOO2, but the essence should be straightforward... The situation in (1) is very similar to the following example, which _is_ detected as erroneous by the compilers I tried: MODULE foo1 CONTAINS SUBROUTINE proc1 END SUBROUTINE proc1 END MODULE foo1 MODULE foo2 USE foo1, ONLY: proc1 USE foo1, ONLY: proc2 => proc1 INTERFACE generic_spec MODULE PROCEDURE proc1 MODULE PROCEDURE proc2 END INTERFACE END MODULE foo2 In both cases, the specific s (and the ) are accessible in MODULE foo2, and the interfaces are explicit anyway. ANSWER: EDIT: SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: submitted Apr. 12, 1996 (first appeared in 96-006r2) ------------------------------------------------------------------------------- NUMBER: 000212 TITLE: EQUIVALENCE of Data Objects of Different Types or Kinds KEYWORDS: EQUIVALENCE limitations DEFECT TYPE: STATUS: X3J3 consideration in progress Section 5.5.1 acknowledges that it is possible to construct equivalences between data objects of different types or kinds: "If equivalenced objects have differing type or type parameters, the EQUIVALENCE statement does not cause type conversion or imply mathematical equivalence." [56:35-36] However, section 5.5.1 also has severe retrictions on equivalences between data objects of differing types and kinds. Following rule R547, there are a series of constraints. Constraints 3 through 6 read: Constraint: If an is of type default integer, default real, double precision real, default complex, default logical, or numeric sequence type, all of the objects in the equivalence set must be these types. Constraint: If an is of type default character or character sequence type, all of the objects in the equivalence set must be of these types. Constraint: If an is of a derived type that is not a numeric sequence or character sequence type, all of the objects in the equivalence set must be of the same type. Constraint: If an is of an intrinsic type other than default integer, default real, double precision real, default complex, default logical, or default character, all of the objects in the equivalence set must be of the same type with the same kind type parameter value. Question 1) Why are these constraints in the standard? What useful purpose do they serve? What problems do they prevent or solve? Question 2) Could a standard-conforming processor relax or eliminate one or more of these constraints, as an extension, without sacrificing full conformance to the standard? Question 3) Can a data object of sequence derived type be equivalenced to another data object of a different sequence derived type? Assume that a processor has among its intrinsic types INTEGER (1) (8 bits), INTEGER (2) (16 bits), and INTEGER (4) (32 bits). Given the following definitions, is the EQUIVALENCE statement standard conforming? TYPE T1 SEQUENCE INTEGER (1) I1_ARRAY (36) END TYPE TYPE T4 SEQUENCE INTEGER (4) I4_ARRAY (9) END TYPE TYPE (T1) OBJECT_1 TYPE (T4) OBJECT_4 EQUIVALENCE (OBJECT_1, OBJECT_4) Question 5) Can an object of sequence derived type be equivalenced to an array of intrinsic type? Assume the definitions of question 3. Is the following EQUIVALENCE statement standard conforming? INTEGER (4) :: I4_ARRAY_9 (9) EQUIVALENCE (OBJECT_1, I4_ARRAY_9) Question 6) Can an object of sequence derived type be equivalenced to a scalar of intrinsic type? ANSWER: EDIT: SUBMITTED BY: Craig Dedo (Craig.Dedo@mixcom.com) HISTORY: submitted Jan. 23, 1996 (first appeared in 96-006r2) -------------------------------------------------------------------------------