PC File: 95-006a5.150 Archive: 95-006r5.A150 -------------------------------------------------------------------------------- NUMBER: 000154 TITLE: EQUIVALENCE and zero-sized sequences KEYWORDS: EQUIVALENCE statement, zero-sized sequences DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 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. Introducing complex semantics to explain the meaning of equivalencing zero-length substrings with each other or with other variables adds little useful functionality to the language. Instead such equivalences should have been prohibited. An edit is included to make the prohibition. ANSWER 2: No. ANSWER 3: No. ANSWER 4: No. ANSWER 5: Yes. EDIT: In section 5.5.1, add a new constraint after the existing constraints [57:17+] "Constraint: A must not have length zero." SUBMITTED BY: Dick Weaver HISTORY: 93-264 m127 submitted 93-323 m127 response approved 14-5 94-034 m128 X3J3 ballot failed 10-18 95-281 m135 revise response, WG5 approved (N1161) -------------------------------------------------------------------------------- NUMBER: 000155 TITLE: Multiple USE statements, rename and only lists. KEYWORDS: USE statement, use renaming, ONLY DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 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. The syntax is such that it might appear only the renames from s are being concatenated into the single . An edit is supplied to make it clear that all items from any contribute to the list of accessible local names and accessible s. 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: 1. In section 11.3.2, in the first sentence after the constraints [158:16] change "the local name is the " to "the local name of a named entity is the " 2. In section 11.3.2, in the 2nd sentence of the 4th paragraph after the constraints [158:21-23] change " and the s and s are interpreted as a single concatenated " to ", the s and renames in s are interpreted as a single concatenated , and entities in the remaining items are accessible by those s or s (they may also be accessible by one or more renames)" 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 95-281 m135 revised response and edits, WG5 approved. -------------------------------------------------------------------------------- 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: 000176 TITLE: Definition of RANDOM_SEED KEYWORDS: RANDOM_SEED intrinsic DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 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 the existing wording in Fortran 90 implies that the integer array value itself is to be called a seed, regardless of the internal interpretation. EDIT 2 clarifies this. 2. Yes, specifying PUT semantics as processor-dependent is correct. This does not mean that seeds of any type and shape are allowed. 3. Yes, the value supplied by PUT may be altered in constructing a seed. Discussion:Edits provided in defect item 000148 describe the operation of RANDOM_SEED and RANDOM_NUMBER. Edits to the description of RANDOM_SEED arguments PUT and GET are provided here. 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." 2. In 13.13.84, RANDOM_SEED, GET argument, replace the last sentence (beginning "It is set by the processor . . .") with [228:12]: "It is assigned the current value of the seed." SUBMITTED BY: Dick Weaver HISTORY: 94-142r1 m129 submitted, approved u.c. 94-221 m130 X3J3 ballot, failed 21-2 94-324r1 m131 revised response, approved 16-1 95-034r1 m132 X3J3 ballot, approved 19-1 HOLD for defect item 000148 95-155 m133 revised response, approved 12-1 95-183 m134 X3J3 ballot, failed 16-2 95-281 m135 revised response and 2nd edit, WG5 approved (N1161) -------------------------------------------------------------------------------- NUMBER: 000179 TITLE: DO variable with POINTER attribute KEYWORDS: DO variable, POINTER attribute DEFECT TYPE: Interpretation STATUS: X3J3 draft response 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: 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 an assignment statement such as: PRT = 10 such as 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. -------------------------------------------------------------------------------- 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: 000183 TITLE: Unambiguous procedure overloading KEYWORDS: generic interface, interface - generic, argument - dummy DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 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 (seemingly forbidden) unambiguous overloading where the number of arguments of each data type are the same: INTERFACE BAD3 SUBROUTINE S1(I,J,A,B) REAL I INTEGER B END SUBROUTINE SUBROUTINE S2(J,I,B,A) REAL I INTEGER A END SUBROUTINE END INTERFACE Was the overly strict nature of the disambiguation rules an unintentional oversight? ANSWER: Yes. A change is needed to the rules in 14.1.2.3 to avoid rejecting examples such as the first two examples shown. While the first two examples can be considered to have been incorrectly rejected by the text in the standard, the text necessary to avoid rejecting the last example is sufficiently complicated to indicate that it was specifically not included in the standard. Future versions of the standard may consider extending the language to include the third example as standard conforming. The change is to allow a difference in the number of arguments of each data type to disambiguate overloads. Discussion: To allow the third example it would be necessary to have text that would place an ordering relationship between the positional disambiguators and keyword disambiguators. Consider the following code fragment, which includes an ambiguous call. This code fragment must be nonstandard conforming. INTERFACE AMBIGUOUS SUBROUTINE S1(I,B,J,A) END SUBROUTINE SUBROUTINE S2(K,I,A,J) REAL:: I END SUBROUTINE END INTERFACE CALL AMBIGUOUS(3, 0.5, A=0.5, J=0) ! Cannot tell which of S1 or S2 to ! call EDITS: 1. In section 14.1.2.3, in the third paragraph [242:38] change "and at least one of them must have a nonoptional dummy argument that" to "and (1) one of them 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 95-281 m135 revised text in question (including 3rd example), revised response to indicate 2nd example will be valid. WG5 approved (N1161). -------------------------------------------------------------------------------- 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 draft response 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 like: 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. -------------------------------------------------------------------------------- NUMBER: 000187 TITLE: TARGET attribute, storage association, and pointer association KEYWORDS: TARGET attribute, association - storage, COMMON block, association - pointer DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 QUESTION: Defect item 92, the response to which has been approved by WG5 and is now in the "B" section of interpretation requests, contains an answer that is desirable but there is no text in the standard that supports the response. X3J3 was no doubt considering the following text from section C.5.3 as the base text for the response but (1) this text is in an appendix, not in the body of the standard, and (2) the text is flawed: "The TARGET attribute ... is defined solely for optimization purposes. It allows the processor to assume that any nonpointer object not explicitly declared as a target may be referred to only by way of its original declared name. The rule in 5.1.2.8 ensures that this is true even if the object is in a common block and the corresponding object in the same common block in another program unit has the TARGET attribute." The only part of 5.1.2.8 that could reasonably be considered the "rule" to which C.5.3 refers is: "An object without the TARGET or POINTER attribute must not have an accessible pointer associated with it." This "rule" does not seem to provide the insurance mentioned in C.5.3. Rather, it seems that this sentence exists to clarify the "may" in the first sentence of 5.1.2.8. That is, it seems to be just reiterating that the following is not standard conforming: INTEGER I INTEGER, POINTER :: P P => I In actuality, there is no way that a pointer can become *pointer associated* with an object that does *not* have the TARGET (or POINTER) attribute. The confusion seems to arise when an object with the TARGET attribute is storage associated with an object that does not have the TARGET attribute. What, then, is the meaning of the sentence in 5.1.2.8 cited above? ANSWER: The sentence from 5.1.2.8 was intended to prohibit a nontarget object from being referenced both via a pointer and via the object's name within a single scoping unit but, it fails to do so. Edits are provided to add the prohibition alluded to in C.5.3. Discussion: The following example is provided to illustrate the problem and clarify the edits: PROGRAM MAIN_PROG ! Variable M (a member of blank common) does not have the TARGET ! attribute. INTEGER M COMMON M INTEGER, POINTER :: P INTERFACE SUBROUTINE SUB(P) INTEGER, POINTER :: P END SUBROUTINE END INTERFACE CALL SUB(P) M = -1 PRINT *, "M = ", M PRINT *, "P's target = ", P END SUBROUTINE SUB(P) INTEGER, POINTER :: P ! Variable M (a member of blank common) has the TARGET attribute. INTEGER, TARGET :: M COMMON M M = 100 P => M END In the main program, the storage unit represented by M and P is accessible by two different methods: the variable name M and the pointer P. The text in C.5.3 is intended to prevent this multiple accessibility but the sentence it is referencing in 5.1.2.8 is not relevant with respect to this example. Pointer P is not pointer associated with variable M in the main program. This could be demonstrated by adding the statement PRINT *, ASSOCIATED(P, M) to the main program but this statement would be invalid because M has neither the POINTER nor TARGET attribute in that scoping unit. Since there is no text in 5.5.2.3 that states that if an item in a common block has the TARGET attribute, it may correspond only with another item (in another declaration of the common block) that also has the TARGET attribute, the edits add this rule. Note that defect item 160 also quotes this same passage from C.5.3 in its question. That defect item resulted in the addition of a constraint that prohibits an object in an EQUIVALENCE list from having the TARGET attribute. Without this prohibition, there could again possibly be more than one avenue of reference to a data object in a single scoping unit. In the common block case, however, it is desirable to allow variables with the TARGET attribute so the edit adds the rule stating if a variable in a common block has the TARGET attribute, any corresponding variable in another instance of the common block with the same name must also have the TARGET attribute. REFERENCES: ISO/IEC 1539:1991 5.5.1 (as modified by defect item 160) EDITS: 1. Delete the second sentence of 5.1.2.8 [48:16-17]. 2. Insert as the (new) last paragraph of 5.5.2.3 [59:42+]: "An object with the TARGET attribute 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, passed 12-1 95-034r1 m132 X3J3 ballot, failed 14-6 95-281 m135 revised text in question and answer. WG5 approved (N1161) -------------------------------------------------------------------------------- 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 draft response 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 introducing the general concept of a block, and is not trying to 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. The source text replacing the INCLUDE line must then contain only insignificant lines (comment and blank lines) or the first statement in that source text must be a CASE statement or an END SELECT 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. -------------------------------------------------------------------------------- NUMBER: 000196 TITLE: Inaccessibility of intrinsic procedures KEYWORDS: intrinsic procedure, INTRINSIC attribute, generic identifier, names class DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 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 " 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) -------------------------------------------------------------------------------- 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: 000201 TITLE: SELECTED_REAL_KIND result KEYWORDS: SELECTED_REAL_KIND, intrinsic, result DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 QUESTION:The Result Value portion of the description of SELECTED_REAL_KIND states in part: "The result has a value equal to a value of the kind type parameter of a real data type with decimal precision, as returned by the function PRECISION, of at least P digits ..., or if no such kind type parameter is available on the processor, the result is -1 if the precision is not available..." When SELECTED_REAL_KIND is invoked with a P value of -1, some vendors return a positive value as the result (almost certainly because they've focused on the phrase "of at least P digits" in the above quote from the standard) and some vendors return -1 (almost certainly because they've focused on the phrase "the result is -1 if the precision is not available" in the above quote from the standard). Question 1:Is either one of these results "more correct" than the other ? Question 2:Are both answers acceptable? ANSWER 1:Yes. For this example, the processor should return a positive value. ANSWER 2:No. Discussion:The phrase "if the precision is not available" in section 13.13.93 of the standard is confusing. Edits are supplied to clarify the intent. EDIT(S):In section 13.13.93, in the paragraph prefaced with "Result Value:" [232:6-7] change "if the precision is not available" to "if the processor does not support a real data type with a precision greater than or equal to P" and change "if the exponent range is not available" to "if the processor does not support a real data type with an exponent range greater than or equal to R" SUBMITTED BY: Larry Rolison HISTORY: 95-175 m134 submitted 95-281 m135 response, approved by WG5 (N1161) -------------------------------------------------------------------------------- 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: 000203 TITLE: Scope of operator/assignment symbols KEYWORDS: intrinsic/defined operators/assignment, local/global entities DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 QUESTION 1: Section 14.4 (Scope of operators) states that "The intrinsic operators are global entities." and that "A defined operator is a local entity.". But a defined-operator (R311) may be an extended-intrinsic-operator (R312) which in turn is an intrinsic-operator (R310). This means that if intrinsic operators are global entities, so are at least some of the defined operators, so the second quotation given above cannot be true. Is this correct ? PROPOSED EDIT: Add " that is not an extended intrinsic operator" after "A defined operator" in [F90,245:30]. QUESTION 2: In Section 14.4, the sentence "Within ..." applies to the first sentence only. Defined-operators (other than extended-intrinsic-ops) have no intrinsic meaning and so "additional operations" makes no sense. Is this correct ? PROPOSED EDIT: Move sentence 2 to the end of 14.4. QUESTION 3: Section 14.5 (Scope of the assignment symbol) does not address the replacement of the intrinsic derived type assignment operation, as defined in 7.5.1.2 and 12.3.2.1.2. Is this correct ? PROPOSED EDITS: Add ", or replace the intrinsic derived type assignment operations" after "operations" in [F90,245:34]. QUESTION 4: The entities under consideration in 14.4 and 14.5 are the operator and assignment SYMBOLS. These are to be distinguished from the associated OPERATIONS in the same way that a generic name is to be distinguished from the specific names it comprises. Is this correct ? PROPOSED EDITS: in [F90,245], replace: * line 29: "operators" => "operator symbols" * line 30: "operators" => "operator symbols" * line 30: "operator" => "operator symbol" * line 31: "operator" => "operator symbol" * After the "Within ..." sentences (lines 30,33), add "The procedures corresponding to these operations are local entities." (The intrinsic operations have no "specific" entities associated with them and so need not be mentioned. If they had, these would be global entities.) ANSWERS: ANSWER 1: Yes. An edit is supplied below to clarify that some defined operators are indeed global entities. ANSWER 2: Yes. Although the word "additional" only applies to the first sentence, the proposed edit does not substantially improve the clarity, and the existing text is not in error. ANSWER 3: Yes. An edit is supplied below which adds the case of redefining the assignment operation when the two arguments have the same derived type. ANSWER 4: Yes. However, the current use of the words "operator" and "operations" already makes this distinction in a sufficiently precise manner. EDITS: 1.In Section 14.4, after "A defined operator" [245:30], add "that is not an extended intrinsic operator" 2.In Section 14.5, after "operations" [245:34], add ", or replace the intrinsic derived type assignment operation" SUBMITTED BY: Michael Hennecke (hennecke@rz.uni-karlsruhe.de) HISTORY: 95-254 m135 submitted 95-281 m135 response, WG5 approved (N1161) ------------------------------------------------------------------------------- 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: REFERENCES: ISO/IEC 1539:1991 (E) section 13.13.74 EDITS: SUBMITTED BY: /jor in response to IBM public comments HISTORY: 95-299 m135 submitted