PC File: 95-006a1.150 Archive: 95-006r1.A150 -------------------------------------------------------------------------------- NUMBER: 000154 TITLE: EQUIVALENCE and zero-sized sequences KEYWORDS: EQUIVALENCE statement, zero-sized sequences DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 5.5.1 and its subsections discuss equivalence association and zero-sized sequences, but not in detail sufficient to answer the following questions: Given the following CHARACTER (LEN=4) :: A, B, C Question 1: are the following equivalence statements valid? COMMON /X/ A COMMON /Y/ B EQUIVALENCE (A, C(10:9)), (B, C(10:9)) ! the same zero-sized object is ! equivalenced to two different ! common blocks. EQUIVALENCE (A, C(10:9)), (B, C(100:90)) ! two different zero-sized objects ! are equivalenced to two different ! common blocks Question 2: is the following equivalence valid EQUIVALENCE (C, C(10:9)) Question 3: Is the following valid? EQUIVALENCE (C(10:9), C(100:90)) Question 4: It is generally the case that given CHARACTER (LEN=4) :: D, E, F then EQUIVALENCE (D, E) EQUIVALENCE (F, E) and EQUIVALENCE (D, E, F) both specify that D is equivalenced to F. Do the following specify the same storage associations? EQUIVALENCE (D, E(2:1)) ! E(2:1) is zero sized EQUIVALENCE (F, E(2:1)) and EQUIVALENCE (D, E(2:1), F) EQUIVALENCE (D, E(2:1)) ! E(2:1) is zero sized EQUIVALENCE (F, E(3:1)) ! E(3:1) is also zero-sized and EQUIVALENCE (D, E(2:1), F) Question 5: is E(2:1) a subobject of E? ANSWER 1: Both equivalence statements are invalid. In section 5.5.1.1 [57:21-22], the standard states that all zero sized sequences in the are storage associated with each other, and with the first storage unit of any non-zero sized sequences. In section 14.6.3.2, the standard states that two storage units that are associated with the same zero sized storage sequence are the same storage unit. In the first equivalence statement in question 1, both A and B are storage associated with the same zero sized storage sequence, namely C(10:9), therefore, A and B are storage associated, which is prohibited, since they are declared in different common blocks. In the second equivalence statement in question 1, the standard is unclear about whether C(10:9) and C(100:90) are the same zero-sized storage sequence. An edit is supplied to clarify this case. Since C(10:9) and C(100:90), are the same zero-sized storage sequence, the second equivalence statement in question 1 is illegal because the equivalence statement declares A and B to be storage associated, but they are declared in different common blocks. ANSWER 2: Yes. ANSWER 3: Yes. ANSWER 4: Yes. ANSWER 5: Yes. EDIT: In section 14.6.3.2 [248:15], after the last sentence in the second paragraph, add "Two zero-sized subobjects of the same object are the same zero sized storage sequence.". SUBMITTED BY: Dick Weaver HISTORY: 93-264 m127 submitted 93-323 m127 response approved 14-5 94-034 m128 X3J3 ballot failed 10-18 -------------------------------------------------------------------------------- NUMBER: 000155 TITLE: Multiple USE statements, rename and only lists. KEYWORDS: USE statement, use renaming, ONLY DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 11.3.2 states: (with some formatting to better show logic, tags added to assist references): R1109 is or [ =>] Constraint: Each must be a public entity in the module. Constraint: Each must be the name of a public entity in the module. ...... More than one USE statement for a given module may appear in a scoping unit. If one of the USE statements is without an ONLY qualifier, (a) all public entities in the module are accessible and (b) the s and s are interpreted as a single concatenated . Questions: 1. Is the syntax ambiguous? Note: R1107 is USE [,] or USE , ONLY: [] R1109 is or [ =>] R522 is or Thus in an can parse either as R1109 or R1109 -> R522 . 2. Can s and s be concatenated as a as specified in (b)? s permit "", while rename lists require " => ". ANSWER: 1. Yes. The syntax is ambiguous ("" should be changed to ""). However removal of the ambiguity will be deferred to the next revision of the standard (Fortran 95). 2. No. Rename and only lists cannot be concatenated as a , however the "renames" in both lists can. An edit is supplied to correct this. Discussion : There are many other places in the standard besides R1109 where the same interpretation can be reached by more than one path through the syntax (e.g. could be removed from R533 since it is a special case of a ). Rather than fix this one ambiguity now, it will be deferred to the more general clean up in Fortran 95. Note that in Fortran 95 the appropriate edits to remove the ambiguity in R1109 are : 1. In section 11.3.2, R1109 [158:11] change "" to "" 2. In section 11.3.2, the first constraint following R1109 [158:13] change "" to "" 3. In section 11.3.2, paragraph beginning "A USE statement" [158:19] change "s" to "s" EDITS: In section 11.3.2, paragraph beginning "More than one" [158:22-23] change "s and s" to "s and renames in s" SUBMITTED BY: Dick Weaver HISTORY: 93-265 m127 submitted 93-305 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 failed WG5 ballot 94-352 m131 revised response, approved u.c. 95-034r1 m132 X3J3 ballot failed 19-1 -------------------------------------------------------------------------------- NUMBER: 000158 TITLE: Leftmost (on a line) negative integer KEYWORDS: integer - negative, negative integer, conformance DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: In many computers today the range of values for integer types is not symmetric. Consider, for example, a machine with 8-bit integer arithmetic (to keep the numbers small). The integer range would typically be -128 to +127 Given an implementation that specifies an integer type with that range, do the following statements conform to Fortran 90? DATA I /-128/ I = - 128 ANSWER: The data statement is valid. r530 is ... / / r532 is ... r533 is ... and -128 is a signed integer constant in the integer range that was described. The assignment statement is NOT VALID. r735 is = following the expr syntax, we eventually find r710 is ... - r701 is r305 is ... r306 is Thus the - is an operator, 128 is an , but is out of range and, therefore, the statement is not valid. Constraining of constants to the range of values is described in 4.0. "Intrinsic data types are parameterized. In this case the set of values is constrained by the value of the parameter ..." and "An example ... is the integer data type. This data type has a processor-dependent set of integer numeric values, each of which is denoted by ..." A program is not standard-conforming if it contains references to integers that are outside the range specified by the processor (1.4). While a standard-conforming processor must detect the use of kind type parameters not supported by the processor, it need not detect the use of integers outside the range of a supported kind. EDIT: None SUBMITTED BY: Dick Weaver HISTORY: 93-277 m127 submitted 94-329r1 m131 response, approved 16-1 95-034r1 m132 X3J3 ballot failed 19-1 -------------------------------------------------------------------------------- NUMBER: 000161 TITLE: Modules and private derived types KEYWORDS: module, private, derived type definition, structure component DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: In compiling Bert Buckley's Fortran-90 algorithms that he made available recently the following issue came up : Section 4.4.1 (p 34) states: The accessibility of a derived type may be declared explicitly by an access-spec in its derived-type-stmt or in an access-stmt (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 ENDTYPE 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. Therefore specifying the public attribute for X and Y is an error. So far so good? Now what about this code : MODULE M2 TYPE FRED INTEGER F1,F2 ENDTYPE 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 illegal here? I think the text in 4.4.1 is inadequate to cover this scenario. I believe the declaration should be illegal but it depends on what is meant by "module containing the definition" in 4.4.1. I think the standard was thinking of the M1 case not the M3 case. The problem as I see it is that module M2 contains the definition of the public type FRED and the module M3 contains the "definition" of the private type FRED. ANSWER: The declaration of X in the module M3 is standard conforming. The questioner correctly points out that the answer 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.1.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 USEing 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. DISCUSSION: 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 -------------------------------------------------------------------------------- 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: 000167 TITLE: Subscripts and Substrings in Initialization expressions KEYWORDS: expression - initialization, subobject, expression - constant, expression - specification DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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 subojects of constants in constant expressions and initialization expressions should also have been applied to variables that are subojects. 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 -------------------------------------------------------------------------------- NUMBER: 000168 TITLE: USE ONLY and NAMELIST KEYWORDS: use association, i/o namelist, ONLY, host association DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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 -------------------------------------------------------------------------------- NUMBER: 000171 TITLE: Equivalence of DBLE(A) and REAL(A,KIND(0.0D0)) Intrinsics KEYWORDS: DBLE intrinsic, REAL intrinsic DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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 -------------------------------------------------------------------------------- NUMBER: 000173 TITLE: Definition of elemental intrinsic subroutine KEYWORDS: intrinsic - elemental DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: 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. For elemental intrinsic subroutines is a requirement, or constraint along the lines of "input and output arguments must not be associated" missing? Alternately, should the text about "same results" be deleted and semantics added to these subroutines similar to those for assignment? ANSWER: EDIT: SUBMITTED BY: Dick Weaver HISTORY: 94-121 m129 submitted -------------------------------------------------------------------------------- NUMBER: 000175 TITLE: What is a "constant specification expression"? KEYWORDS: constant specification expression, expression - constant, specification expression - constant, expression - specification DEFECT TYPE: STATUS: X3J3 consideration in progress 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: EDIT: SUBMITTED BY: Dick Weaver HISTORY: 94-137 m129 submitted -------------------------------------------------------------------------------- NUMBER: 000176 TITLE: Definition of RANDOM_SEED KEYWORDS: RANDOM_SEED intrinsic DEFECT TYPE: Erratum STATUS: Hold, X3J3 approved; HOLD for defect item 000148 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. Alternately 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. Yes, for GET "TRANSFER" semantics were intended, however "processor dependent" is both more general and parallels the PUT edit. 2. Yes, specifying PUT semantics as processor-dependent is correct. 3. Yes, the value supplied by PUT may be altered in constructing a seed. Edits provided in defect item 000148 describe the operation of RANDOM_SEED and RANDOM_NUMBER. An edit to the description of RANDOM_SEED argument PUT is provided here. EDIT: 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." 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 -------------------------------------------------------------------------------- NUMBER: 000177 TITLE: Structures in EQUIVALENCE lists KEYWORDS: derived type, EQUIVALENCE statement, SEQUENCE, pointer DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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 -------------------------------------------------------------------------------- NUMBER: 000179 TITLE: DO variable with POINTER attribute KEYWORDS: DO variable, POINTER attribute DEFECT TYPE: Erratum 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. Did the standard mean to allow a DO variable to have the POINTER attribute? ANSWER: No. This oversight has been remedied by an edit. Discussion: The description of the iterative form of the DO loop was essentially carried forward from the previous standard. It was an oversight to prohibit the DO variable from having the POINTER attribute. Prohibiting the POINTER attribute prevents the confusion that can arise as demonstrated by the example programs given above. EDIT(S): Section 8.1.4.1.1 following the first constraint following rule R822 [100:39+] insert the new constraint: Constraint: The must not have the POINTER attribute. SUBMITTED BY: Larry Rolison HISTORY: 94-226r1 m130 submitted, approved 10-1 94-306 m131 X3J3 ballot approved 19-0 -------------------------------------------------------------------------------- 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: 000181 TITLE: in STOP and PAUSE statements KEYWORDS: STOP, PAUSE DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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 -------------------------------------------------------------------------------- NUMBER: 000182 TITLE: Intrinsics in statement functions KEYWORDS: statement function, interface - explicit DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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, if it is not an intrinsic, must not require an explicit interface, 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 -------------------------------------------------------------------------------- NUMBER: 000183 TITLE: Unambiguous procedure overloading KEYWORDS: generic interface, interface - generic, argument - dummy DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: The standard considers (14.1.2.3) the following example to be ambiguous: INTERFACE BAD SUBROUTINE S1(A) END SUBROUTINE SUBROUTINE S2(B,A) END SUBROUTINE END INTERFACE ! BAD because it 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 (apparently forbidden) unambiguous overloading where the number of arguments of each data type are the same: INTERFACE BAD3 SUBROUTINE S1(I,J,A,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 example shown. While the first example can be considered to have been incorrectly rejected by the text in the standard, the text necessary to avoid rejecting the other two examples 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 second and third examples 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 second and third examples 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 has 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 -------------------------------------------------------------------------------- NUMBER: 000184 TITLE: Intent of intrinsic dummy arguments KEYWORDS: INTENT, intrinsic, argument - dummy, INTENT(IN) DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress 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: Add a new section 13.4 [184:1] and renumber all following sections appropriately. "13.4 Argument intents 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 -------------------------------------------------------------------------------- NUMBER: 000185 TITLE: What is the allocation status of an array after an allocation failure? KEYWORDS: ALLOCATE, POINTER, DEALLOCATE, status DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: It does not appear that the standard define the allocation status of an array if an ALLOCATE statement fails and returns a nonzero STAT= value. Given a program like: REAL ALLOCATABLE DIMENSION(:) :: A,B,C ALLOCATE(A(10), B(10), C(10), STAT = ISTAT) 1) If istat comes back non-zero, is it possible to deallocate the arrays and try to reallocate them with smaller sizes? 2) If instead of being allocatable they had been pointers could NULLIFY be used? 3) Are the answers different if there was only a single array in the allocate rather than a list? 4) If a DEALLOCATE fails for a list what is the allocation status of the arrays? 5) Is it acceptable to use the ALLOCATED and/or ASSOCIATED functions to attempt to recover from a failure? 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 an stat= parameter). If an input statement fails then everything in the list becomes undefined. Does that apply by analogy to allocate? ANSWER: DISCUSSION: EDITS: SUBMITTED BY: Dick Hendrickson HISTORY: 94-296r1 m131 submitted -------------------------------------------------------------------------------- NUMBER: 000186 TITLE: Allowed values of POSITION= specifier when changing BLANK= KEYWORDS: OPEN statement, POSITION= specifier DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: What values are allowed for the POSITION= specifier when an OPEN is used to "reopen" a file and change the BLANK= etc, specifiers? 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..." What is the value of the POSITION= specifier? 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 non-standard. Is this a correct reading? It's not completely obvious that 2 is standard conforming. Page 115, line 23 says 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, page 117, line 25 says that the default value for the position specifier is "ASIS". 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? There is a set of similar questions for STATUS. If the STATUS= is omitted on the reopen it defaults to "UNKNOWN". 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. There may be a problem with any specifier that has a default value. Was it the intent that all of the specifiers that do not have default values be specified when BLANK=, etc., are used to modify a connection? ANSWER: DISCUSSION: EDITS: SUBMITTED BY: Dick Hendrickson for meeting 131 HISTORY: 94-297r1 m131 submitted -------------------------------------------------------------------------------- NUMBER: 000187 TITLE: TARGET attribute, storage association, and pointer association KEYWORDS: TARGET attribute, association - storage, COMMON block, association - pointer DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Interpretation Request 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 seem to be just reiterating that you can't do the following: 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. There is pointer association and there is storage association but pointer association does not "transmit" through storage association. 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, as you point out, it fails to do so. Edits are provided to add text to provide 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 Interpretation Request 160 also quotes this same passage from C.5.3 in its question. That Interpretation Request 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 that 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 Interpretation Request 160) EDIT(S): 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 must become storage associated only with another object that has the TARGET attribute." 3. Delete the fourth sentence of C.5.3 [269:23-25]. SUBMITTED BY: Larry Rolison HISTORY: 94-299r1 m131 submitted, with proposed response 95-034r1 m132 X3J3 ballot, failed 14-6 -------------------------------------------------------------------------------- NUMBER: 000188 TITLE: Ambiguity in Namelist Input? KEYWORDS: i/o namelist, value separator, logical value DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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) eg: &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., (eg: 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(S): 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 -------------------------------------------------------------------------------- NUMBER: 000189 TITLE: Module name / local name conflict KEYWORDS: name - class, use association, global entity DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: The question in this Interpretation Request is a variation on Interpretation Request 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. EDIT(S): None SUBMITTED BY: Larry Rolison HISTORY:94-301 m131 submitted with proposed response, approved u.c. 95-034r1 m132 X3J3 ballot, approved 20-0 -------------------------------------------------------------------------------- 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) / EDIT(S): 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. REFERENCES: 4.4.2 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: 000192 TITLE: Ambiguity of dummy procedures in interface bodies KEYWORDS: dummy procedures, interface bodies DEFECT TYPE: STATUS: X3J3 consideration in progress 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. I would have thought 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. Therefore, my questions are: Question 1: Should a procedure interface body unambiguously identify dummy procedures and their nature (i.e. function or subroutine)? Question 2: If so, 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: EDITS: SUBMITTED BY: John Merlin HISTORY: 94-307 m131 submitted -------------------------------------------------------------------------------- NUMBER: 000193 TITLE: List-directed Output of Character Constants KEYWORDS: List directed, I/O, delimiters DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress Consider the following statements from Section 10.8.2: The first two lines of section 10.8.2 state: The form of the values produced is the same as that required for input, except as noted otherwise. With the exception of adjacent nondelimited character constants, the values are separated by one or more blanks or by a comma optionally preceded by one or more blanks and optionally followed by one or more blanks. Later in Section 10.8.2, it gives the following list: Character constants for an internal file, or for a file opened without a DELIM= specifier (9.3.4.9) or with a DELIM= specifier with a value of NONE: (1) Are not delimited by apostrophes or quotation marks, (2) Are not separated from each other by value separators, (3) Have each internal apostrophe or quotation mark represented externally by one apostrophe or quotation mark, and (4) Have a blank character inserted by the processor for carriage control at the beginning of the record that begins with the continuation of a charcter constant from the preceding record. The wording of the second item in the list is not as clear as the wording in Fortran 90 for character constants produced for a file opened with a DELIM= specifier of QUOTE or APOSTROPHE: Character constants produced for a file opened with a value of QUOTE are delimited by quotes, are preceded and followed by a value separator, and have each internal quote represented on the external medium by two contiguous quotes. The phrase "Are not separated from each other" could be taken to mean that there is no value separator between two character constants but does not seem to address the value separator between a noncharacter constant and a character constant. The wording in the Fortran 77 standard for the same output of character constants was very clear: Character constants produced are not delimited by apostrophes, are not preceded or followed by a value separator, have each internal apostrophe represented externally by one apostrophe, and have a blank inserted by the processor for carriage control at the beginning of any record that begins with the continuation of a charcter constant from the preceding record. An example of the problem is: INTEGER :: IELT(2) CHARACTER*14 CHTEXT(3) CHARACTER*80 CHBUF CHTEXT(1) = 'Test of delim=' CHTEXT(2) = '"NONE" and val' CHTEXT(3) = 'ue separators.' IELT(1) = 111 IELT(2) = 999 WRITE(CHBUF,*) IELT(1), CHTEXT, IELT(2) PRINT *, CHBUF OPEN(UNIT=1, DELIM='APOSTROPHE') WRITE(1,*) IELT(1), CHTEXT, IELT(2) END The contents of the internal file CHBUF under Fortran 77 are: 111Test of delim="NONE" and value separators.999 Depending on the interpretation of Fortran 90, the contents of CHBUF with a blank as value separator may be: 111 Test of delim="NONE" and value separators. 999 The content of the unit one record with a blank as value separator and with DELIM='APOSTROPHE' specified is: 111 'Test of delim=' '"NONE" and val' 'ue separators.' 999 Question 1: Does the Fortran 90 standard, for list-directed character constant output, allow the use of a preceding value separator when the preceding list item was a noncharacter constant? There are at least two different implementations of this specific area for Fortran 90. Question 2: Is the trailing separator between a character constant and a noncharacter constant allowed? If this additional capability is allowed, this difference between Fortran 77 and Fortran 90 should be documented. ANSWER 1 and 2: Yes. The Fortran 90 standard requires a value separator between a nondelimited character constant and an adjacent non-character constant in the context of list directed output. DISCUSSION: Fortran 77 and Fortran 90 are potentially incompatibile in this area. The potential for incompatibility arises from an imprecise description in the Fortran 77 standard. The Fortran 77 standard states in section 13.6.2: "With the exception of character constants, the values are separated by one of the following: (1) One or more blanks" The confusion in Fortran 77 is whether the phrase "character constants" above meant adjacent character constants, or included a single character constant preceeded or followed by a non-character constant. Consider the following Fortran 77 example: INTEGER J WRITE(6,*) "ABC", J In this example, a Fortran 77 processor is required to produce an integer constant representing the value of "J", with the effect of an "Iw" edit descriptor, for some reasonable value of "w". The processor is free to chose a value for "w" which will produce leading blanks, which appear immediately after "ABC" in the output record. Fortran 77 clearly allows a value separator after a character constant in this case (although not necessarily produced when the character item is processed); therefore, it is possible that the phrase "character constants" in the first paragraph of section 13.6.2 meant "adjacent character constants". This is the interpretation the committee chose when writing the Fortran 90 standard. Note that this is NOT an official interpretation for Fortran 77. The so-called "gsa" validation suite appears to allow a processor to put value separators before a character constant, in this context, when the item before the character value is not of type character. Also note that several existing validated Fortan 77 processors do not fully comply with this interpretation of the Fortran 77 standard. For these particular Fortran 77 processors, the form of some list directed output data may differ from a standard conforming Fortran 90 processor. In the Fortran 90 standard, section 10.8.2, Item (2) (as you noted) is not clear about when value separators are omitted, but the first paragraph in section 10.8.2 is clear. A Fortran 90 processor is required to insert a value separator between all constants produced by a list directed output statement except in the case of two adjacent nondelimited character constants. EDIT(S): None. SUBMITTED BY: Joanne Brixius HISTORY: 94-325 m131 submitted 95-019 m132 proposed response -------------------------------------------------------------------------------- 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: Erratum 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 is imprecise and is clarified in an edit. 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. The INCLUDE file must then contain only insignificant lines (comment and blank lines) or the first statement in the INCLUDE file must be a CASE statement or an END SELECT CASE statement. EDIT: Page 95, the sentence before rule R801 [95:12] insert "and possibly FORMAT and DATA statements" between "constructs" and "that". 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 -------------------------------------------------------------------------------- NUMBER: 000195 TITLE: INQUIRE with pre-connected files KEYWORDS: INQUIRE statement DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: If unit 3 is pre-connected 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 pre-connected 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 pre-connection 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 say 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 chose 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 talks about 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. EDIT(S): None. SUBMITTED BY: Peter Griffiths HISTORY: 95-014 m132 submitted 95-018 m132 proposed response -------------------------------------------------------------------------------- NUMBER: 000196 TITLE: TARGET dummy arguments and element sequence calls KEYWORDS: TARGET, dummy argument DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: In a call, if an actual argument is an array element of a dummy argument that is not assumed-shape but has the TARGET attribute, does the corresponding dummy argument have to be scalar? Section 12.4.1.1, "Arguments associated with dummy data objects", states: "If the actual argument is scalar, the corresponding dummy argument must be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element." Thus examples such as the following are standard conforming: INTEGER :: A(10) CALL SUB(A(4)) END SUBROUTINE SUB(ARRAY) INTEGER :: ARRAY(4) ... This question is asking whether examples such as the following are standard conforming. PROGRAM P INTEGER, TARGET :: ACTUAL(100) CALL SUB(ACTUAL(1:20:2)) CONTAINS SUBROUTINE SUB(DUMMYTARGET) INTEGER, TARGET :: DUMMYTARGET(10) CALL SUBARRAY(DUMMYTARGET(5)) ! DUMMYTARGET(5) and DUMMYTARGET(6) ! do NOT represent contiguous pieces of ! storage. END SUBROUTINE END PROGRAM SUBROUTINE SUBARRAY(DUMMYARRAY) INTEGER :: DUMMYARRAY(2) DUMMYARRAY = 5 END SUBROUTINE ANSWER: Yes, the corresponding dummy argument must be scalar. The last example shown in the question is not standard conforming. DISCUSSION: Array elements of an array that is assumed-shape or a pointer array are not allowed to appear as the actual argument when the corresponding dummy argument is not scalar. The cited text, which makes this restriction, should have also made a similar restriction if the actual argument is an array element of a dummy argument with the TARGET attribute. An edit is provided to extend the restriction. Assumed-shape arrays, pointer arrays and dummy argument arrays with the TARGET attribute may represent non-contiguous storage. To allow array elements of such arrays to be passed to routines expecting a contiguous array would mean that most implementations would make a copy of the array prior to the call. If no explicit interface is available an implementation may not know if a routine being called with an array element actual argument, is expecting a scalar or an array. The implementation would not know if the copy was necessary or not; it would make the copy anyway. To avoid such unnecessary copying, it is better to restrict calls such that if the actual argument is an array element of an assumed-shape array, a pointer or a dummy argument array with the TARGET attribute, the corresponding dummy argument must be a scalar. EDIT: In Section 12.4.1.1, replace the sentence [173:18-20] "If the actual argument is scalar, the corresponding dummy argument must be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element." with "If the actual argument is scalar, the corresponding dummy argument must be scalar unless the actual argument is: (1) an element of an array, that is not one of the following: (a) the element of an assumed-shape array, (b) the element of a pointer array, or (c) the element of a dummy argument array with the TARGET attribute, or (2) a substring of an element permitted by (1)." SUBMITTED BY: Janice C. Shepherd HISTORY: 95-031r1 m132 submitted with proposed answer -------------------------------------------------------------------------------- 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: 000198 TITLE: Characteristics of dummy procedures KEYWORDS: DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress 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 the code fragments are standard conforming. 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 those of 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. An edit is included to clarify this intent. EDIT: Section 12.4.1.2, [173:35-36] change "the characteristics of the associated actual argument must be the same as the characteristics of the dummy procedure (12.2)" to "the characteristics of the associated actual argument as a procedure must be the same as the characteristics of the dummy procedure as a procedure (12.2)" SUBMITTED BY: Janice C. Shepherd HISTORY: 95-042 m132 submitted, with proposed response