From jwagener@amoco.com Sat Feb 20 07:20:08 1993 Received: from interlock.amoco.com by dkuug.dk with SMTP id AA19736 (5.65c8/IDA-1.4.4j for ); Sat, 20 Feb 1993 20:20:17 +0100 Received: by interlock.amoco.com id AA10338 (InterLock SMTP Gateway 1.1 for SC22WG5@dkuug.dk); Sat, 20 Feb 1993 13:13:01 -0600 Received: by interlock.amoco.com (Internal Mail Agent-2); Sat, 20 Feb 1993 13:13:01 -0600 Received: by interlock.amoco.com (Internal Mail Agent-1); Sat, 20 Feb 1993 13:13:01 -0600 Date: Sat, 20 Feb 93 13:20:08 CST Message-Id: <9302201920.AA16824@trc.amoco.com> From: Jerrold L. Wagener To: SC22WG5@dkuug.dk Subject: X3J3/93-006r, subset for Mar 1-30 X3J3 ballot X-Charset: ASCII X-Char-Esc: 29 ###################################################################### # # # X3J3/93-006r - ballot subset # # # # February 1993 # # # ###################################################################### Number Title Status 000000 Minor edits and corrections to ISO/IEC 1539:1991 (E) -a 3 -b 2 000001 Equivalence of Expression Evaluations 3 000002 Default Main Program Name 3 000003 Preconnected Units and UNIT=* 3 000004 Blanks in Format Specifications in Free Form Source 2 000005 Namelist Output of Zero Length Character Strings 3 000006 Procedure Specifications in a Scoping Unit 3 000007 Duplicate module procedures in interface blocks 1 000008 - subsumed by 7 - 000009 Generic Interfaces with the Same Name in a Program 3 000010 Generic Interfaces with the Same Name in a Scoping Unit 3 000011 Multiple Accessible Defined Assignment Interfaces 2 000012 Type of a Named Constant 3 000013 Implicit Environment of an Interface Block 3 000014 Interface for a Character Function with a Variable Length Result 3 000015 Error in Fourth Constraint for R429 3 000016 Character Length Specification 3 000017 Creation of Entities by Local Names in rename-list 3 000018 Valid Characters for Indicating Fixed Form Statement Continuation 3 000019 Correctness of Last Example in Section 4.5 3 000020 References to the Same Derived Type by Different Names 3 000021 References to Different Derived Types with the Same Name 3 000022 Use of Derived Type Name in Host Scoping Unit 3 000023 - subsumed by 12 - 000024 IMPLICIT NONE and the Type of an Internal Procedure Result 3 000025 Resolution of Internal Procedure References 3 000026 Bounds of Array Expressions 3 000027 Requirements for Pointers and Target Association 2 000028 Precedence of Use or Host Association 1 000029 Class of a Defined Operator 2 000030 Length of Character Literals in Array Constructors 2 000031 Overloaded Implied-DO Variable Names 3 000032 Implicit Declaration of a Derived Type 3 000033 Interface Blocks with the Same Name in a Program 3 000034 - subsumed by 33 - 000035 - subsumed by 33 - 000036 Pointer to an Assumed-size Array 3 000037 Use of Array Sections in Pointer Assignment Statements 3 000038 Same Interface Body in Multiple Generic Interface Blocks 3 000039 Association of a Pointer Actual Argument with a Dummy Argument2 000040 Allocation of Arrays of Pointers 3 000041 Procedure with Target Dummy Argument Requires Explicit Interface 2 000042 KIND parameter value 3 000043 List-directed character input 3 000044 END Statement and Fixed Form Source 3 000045 Array Intrinsics with Arrays of Derived-type Arguments 3 000046 RESULT clause for RECURSIVE functions 3 000047 Automatic data object in initialization expressions 3 000048 Pointer-valued statement functions 3 000049 Characteristics of Function Results 1 000050 Repeat counts on edit descriptors 3 000051 On Unambiguous generic procedure references 3 000052 Expressions in Statement Function Definitions 3 000053 Optional Intrinsic Function Arguments 3 000054 Resolving Generic Procedure References 3 000055 Characteristics of character function results 3 000056 TRANSFER intrinsic function description 3 000057 Prohibition against multiple explicit specific interfaces 3 000058 Ambiguous use of "keyword" 2 000059 SEQUENCE derived type and component bounds 3 000060 Statement function argument references 3 000061 G edit descriptor with "d" = 0 3 000062 Statement function constraints 3 000063 Interfaces and dummy procedure arguments 3 000064 SPACING result for 0.0 3 000065 Block and Nonblock DO Construct 3 000066 Declaration of FUNCTION type 3 000067 Output of negative signed zero 3 000068 Pointer association status 3 000069 I/O implied DO variable 3 000070 Characteristics specified by interface bodies 2 000071 USE association and COMMON block name 2 000072 Missing constraint for SIZE= 3 000073 Description of the MERGE intrinsic function 2 000074 Meaning of "referenced" in 11.3.2 3 000075 Interface blocks in block data 2 000076 Attributes, Properties, Characteristics 1 000077 Misc. questions 1 000078 Intrinsic functions in MODULE specification statements 3 000079 Automatic character and ALLOCATABLE, ... attributes 2 000080 Vector subscripts in masked array assignment statements 3 000081 Pointer actual argument overlap 1 000082 Host association, generic name 2 000083 Generic Override of Intrinsic Procedure 1 000084 Change masked array assignment constraint to prose 3 000085 Nondefault Integer Data Type for UNIT=, ... Specifiers 3 000086 USE and Host Association 2 000087 PARAMETER statements and SAVE statements 2 000088 Common block names and local names 1 000089 Errors in the DATA statement description 2 000090 Subroutine and Function names in nested scopes 1 000091 Constraint diagnosis for SEQUENCE attributes 2 000092 Pointer and Storage Association 2 000093 Scalar Pointer Function Results 2 000094 Functions in WRITE statement implied-DO loops 3 000095 Functions in IOLENGTH implied-DO loops 3 000096 Definition of "Declaration" 1 000097 Specification Expression 2 000098 KIND param and list directed I/O 3 000099 Generic interfaces 1 000100 ASSOCIATED intrinsic and zero sized objects 2 000101 Specification statements 1 000102 Returned value for INQUIRE POSITION= on an empty file 3 000103 Statement Function with unreferenced dummy argument 3 000104 rounding formatted output 3 000105 Parallel Evaluation of Operands and Arguments 2 000106 Multiple USE of modules; renaming rules 2 000107 USE renaming of generic and specific interfaces 3 000108 Referencing disassociated pointers 2 000109 Intrinsic Function ASSOCIATED 3 000110 Named Constant Shape Specification 3 000111 Array constructors in masked assignment statements 1 000112 Sequence Derived Type External Functions 2 000113 Ordering of Array Specification and Initialization 2 000114 Named Constant Attribute Specification 3 000115 Multiple dummy arguments 3 000116 Scoping Units and statement labels 3 000117 Use of MODULE PROCEDURE Statement in Internal Procedures 2 000118 Named constructs and host association 3 000119 Rank of assumed-shape array 3 000120 PRESENT intrinsic and host association 3 000121 ";" As a Statement Separator 1 000122 Intrinsic Procedures in Modules 1 000123 Result of INT(A) not equal to A for non-default integers 2 000124 Result of LBOUND for assumed-size arrays 1 000125 Copy in/ Copy out of Target Dummy Arguments 2 000126 Character Entry statements and Partial Association 1 000127 Is a module a global entity? 1 000128 Use associated generic names and renaming 1 000129 Array constructors in initialization expressions 2 000130 Multiple statements on line with END statement 2 status 1: X3J3 consideration in progress status 2: X3J3 draft response status 3: X3J3 approved; ready for WG5 The status 2 items are listed below and will be on the March 1-30 X3J3 letter ballot. Please send any corrections by Feb 24 so that they can be incorporated into the ballot. Note that any formatting errors are most likely due to the ascii-ization and mono-fonting of these items for this email distribution. ============================================================== NUMBER: 000000-b TITLE: Minor edits and corrections to ISO/IEC 1539:1991 (E) KEYWORDS: edits, typos, typographical errors DEFECT TYPE: Erratum STATUS: X3J3 draft response 1. 11.3.3.7, in the second sentence, change "C.11.5" to "C.11.4" 2. Annex A, host association [257:29]; Change "11.2.2" to "12.1.2.2.1". 3. Annex C, first example [273:14]; change "ENDTYPE" to "END TYPE". HISTORY: Submitted at X3J3 meeting 124, Feb 1993, papers 93-036, 93-078, 93- 081 -------------------------------------------------------------------------- NUMBER: 000004 TITLE: Blanks in Format Specifications in Free Form Source KEYWORDS: free form source, format specification, blanks DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Is the following format specification valid in free form source? FORMAT (B N) ANSWER: Yes. Discussion: Sections of Fortran 90 are not consistent. 3.3.1: In free form, blank characters must not appear within lexical tokens other than in a character context. and A blank must be used to separate names, constants, or labels from adjacent keywords, names, constants, ... 10.1.1: Additional blank characters may appear at any point within the format specification, with no effect on the interpretation of the format specification, except within a character string edit descriptor. It can be seen that the text in chapter 3 does not consider edit descriptors. The text will be revised so that: -- edit descriptors are not in the category "keywords" and need not be delimited by blanks. -- blanks are allowed in edit descriptors. Note that the first edit below depends on a change made in item 58 which moves the line from section 3.2.1 to 2.5.2 REFERENCES: ISO/IEC 1539:1991 (E) sections 3.3.1, 10.1.1 EDIT(S): 1. Section 2.5.2 following the sentence "Keywords appear ... through 12." add the following: "Note that in addition to keywords, upper-case letters may also appear in various other lexical tokens. Examples include operators such as .EQ., edit descriptors such as BN or Iw[.m], and literal constants such as B'digit[digit]...'." 2. Section 3.2 page 19 last sentence [19:35-36] insert ", edit descriptors" following "... , labels". 3. Section 3.3.1, page 22, second paragraph, change "... character context." to "... character context or in a format specification." SUBMITTED BY: J.T. Martin 119-JTM-2 (119.015) HISTORY: 119-JTM-2 119-RPK-1 X3J3/92-044 S20.120, number 4 X3J3/92-075 X3J3/92-145 Draft Interpretation by CIO, withdrawn Approved as X3J3/92-176 at meeting 122 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000011 TITLE: Multiple Accessible Defined Assignment Interfaces KEYWORDS: interfaces, defined assignment DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following excerpts from section 14.1.2 [241]: Excerpt (a): Within a scoping unit, entities in the following classes: (1) Named variables that are not statement entities (14.1.3),..., generic identifiers, derived types, and namelist group names ... are local entities of that scoping unit. Excerpt (b): Within a scoping unit, a name that identifies a local entity of one class must not be used to identify another local entity of the same class, except in the case of generic names (12.3.2.1). A name that identifies a local entity of one class may be used to identify a local entity of another class. The standard defines both the terms "generic identifier" and "generic name" in section 12.3.2.1 [168]. "Generic identifier" is defined to encompass the three concepts of a generic name, a defined operator, or an equals symbol on a generic specification. "Generic name" refers to the BNF term for the name that may appear on an interface specification. The text from section 14 cited in (a) uses the term "Generic identifier" but the text cited in (b) uses the term "generic name". Is the intent behind the choice of different words in section 14 to prohibit a program from containing multiple interface blocks for the same operator and multiple accessible defined assignment interfaces? ANSWER: No. Discussion: Section 11.3.2 states: "If two or more generic interfaces that are accessible in a scoping unit have the same name, the same operator, or are both assignments, they are interpreted as a single generic interface" Thus, two or more interfaces that have the same name, the same operator, or are assignment interfaces are not only permitted but the interfaces are considered to be a single generic interface. The text cited in (b) above was specifically discussing "names" and hence "generic names" were singled out. While the text cited in (a) above was discussing all entities that are local to a scoping unit, not just named entities. REFERENCES: ISO/IEC 1539:1991 (E) sections 11.3.2, 12.3.2.1, & 14.1.2 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-4 (120.029), question 3 LAST SIGNIFICANT CHANGE: before meeting 123 000011 HISTORY: Originally passed as 120-MBSH-1A (120.084A) Revised in response to ballot comments at meeting 123, but no vote taken - withheld for further consideration Slight rewording for clarification in 93-029 Approved by unanimous consent at meeting 124. ----------------------------------------------------------------------- NUMBER: 000027 TITLE: Requirements for Pointers and Target Association KEYWORDS: POINTER attribute, TARGET attribute, pointer association DEFECT TYPE: Interpretation STATUS: X3J3 draft proposal QUESTION: If PTR has the POINTER attribute and TGT has the TARGET or POINTER attribute, under which of the following other conditions are PTR and TGT considered to be pointer associated, i.e., under which of the following conditions does ASSOCIATED(PTR, TGT) return a value of .TRUE.: a) PTR and TGT have different types? b) PTR and TGT have different type parameters? c) PTR and TGT have different ranks? d) PTR and TGT have different sizes? e) PTR and TGT have different shapes? f) PTR and TGT have different bounds? g) PTR and TGT refer to the same set of array elements/storage units, but not in the same array element order? h) PTR and TGT have array elements/storage units whose range of memory addresses overlap, but they have no identical array elements/storage units? i) PTR and TGT have at least one but not all identical array elements/storage units and all the identical elements have the same subscript order value in both PTR and TGT? j) PTR and TGT have at least one but not all identical array elements/storage units but not all the identical elements have the same subscript order value in both PTR and TGT? ANSWER: Except under conditions where the value of ASSOCIATED is undefined, any of the above conditions except for f) are sufficient for ASSOCIATED (PTR, TGT) to return a value of .false.. In determining whether a pointer and a target are associated, the bounds are not relevant, but the extents are. The extents of each dimension of PTR and TGT must be the same, thus their shapes must match which is covered by condition (e). Discussion: There are only three means by which a pointer may become pointer associated: via the ALLOCATE statement (6.3.1), via pointer assignment (7.5.2), or via argument association (12.4.1.1). In an ALLOCATE statement, the object created inherits its type, type parameters, rank, shape, size and bounds from those declared for, or specified with, the pointer name. In a pointer assignment, the type, type parameters, and rank of the pointer and target must conform, and the shape and size of the target determine those of the pointer. When a pointer actual argument is passed to a pointer dummy argument, the pointer dummy argument becomes pointer associated with the same target as the pointer actual argument. In all three of these cases, array elements of the pointer and the target correspond with one another in array element order. Thus, since there is no other way for two objects to become pointer associated, all these properties must be the same. The result of the two-argument form of ASSOCIATED is undefined if either argument is a pointer that is currently associated with a target that is zero sized, or the second argument is not a pointer but is zero sized. Note that other forms of association (name association and storage association) are distinct from, and orthogonal to, pointer association (14.6). REFERENCES: ISO/IEC 1539:1991 (E) 5.1.2.4.3, 6.3.1, 7.5.2, 12.4.1.1, & 14.6 EDIT(S): None. SUBMITTED BY: J. L. Steidel, 120-JLS-4 (120.022) LAST SIGNIFICANT CHANGE: 1993-02-12 000027 HISTORY: 120-LJM-3A (120.081A) Original response proposed at meeting 121 Questioned in X3J3/92-061 (121-ADT-9) p9 & X3J3/92-061 (121-ADT-13) item 27 Approved as X3J3/92-093A at meeting 121 Approval rescinded at meeting 123 (uc) Revised response in X3J3/93-099r1 adopted at meeting 124 by a vote of (15-2) ----------------------------------------------------------------------- NUMBER: 000029 TITLE: Class of a Defined Operator KEYWORDS: defined operator, generic identifier, classes of local entities DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Is a defined operator name a generic identifier? Thus is it illegal for a defined operator name to be the same as another class 1 entity within the same scoping unit (as defined in 14.1.2)? ANSWER: No. The word 'name' is used in a technical way throughout the standard. It is defined by R304 on page 19 and is not used in the definition of defined-operator by R311, R704, R724 on page 21. A defined operator is a generic identifier (see page 168, lines 12 and 11 from the bottom), but it does not have a name. Therefore the rule in 14.1.2 does not apply. This is analogous to the situation for intrinsic operators, where it is permissible to have local variables named AND, OR, etc. REFERENCES: ISO/IEC 1539:1991 (E) sections 3.2.2, 3.2.4, 12.3.2.1, 14.1.2 EDIT: None. SUBMITTED BY: J. L. Steidel, 120-JLS-7 (120.025) HISTORY: 120-RL-2A (120.059A) 121-LRR-8 Opposed to 121-JKR-2 121-JKR-2 Opposed to S20/29 (120-59a) X3J3/92-106 Interpretation based on 121-JKR-2 Approved as X3J3/92-148A at meeting 122 by unanimous consent Approved as X3J3/92-252 by unanimous consent at meeting 124 -------------------------------------------------------------------------- NUMBER: 000030 TITLE: Length of Character Literals in Array Constructors KEYWORDS: array constructor, character literal, character length, substring DEFECT TYPE: Erratum STATUS: X3J3 drafrt response QUESTION: Consider the following example: CHARACTER :: NAMES (3) * 20 NAMES = (/ 'TOM', 'DICK', 'HARRY' /) This appears to be invalid due to a constraint in section 4.5, "Construction of array values": Constraint: Each expression in the must have the same type and type parameters. The length of the string is a type parameter. Thus the array constructor sample above is invalid because the strings have different lengths. Consider another example: CALL SUB ( (/ 'TOM', 'DICK', 'HARRY' /) ) ... SUBROUTINE SUB (NAMES) CHARACTER :: NAMES(:) * (*) WRITE(*,*) LEN(NAMES) ... This also appears invalid. 1. Must each character string literal constant in an array constructor be the same length? 2. If the answer to 1 is "No", what values are printed by the second example? 3. If the answer to 1 is "Yes", another question arises. The syntax of an array constructor is described in section 4.5. In rule R432, ac-value is defined to be an expr or an ac-implied-do. Since an ac-value may be an expression, a substring is a valid ac-value. Therefore each substring in an array constructor must have the same length and that length must be the same as the length of every other ac-value in the constructor. But a substring can contain nonconstant expressions as the starting point and ending point, or the starting point and ending point can be omitted (signaling the use of a default value). Since a substring can contain nonconstant starting and ending points, the constraint cited above cannot be detected at compile time and thus cannot be a constraint. Should this restriction be rephrased as prose in the text of the standard? ANSWER: The answer to question 1. is yes. Each character literal constant in an array constructor must be the same length. Both examples are nonstandard conforming. The answer to question 3. is yes. The following edits move the equal-length requirement from a constraint to prose in the text. Discussion: The awkwardness resulting from the requirement that each ac- value be the same length was noted by X3J3, but the committee could not reach agreement on an acceptable way to allow character literal constants of differing lengths in an array constructor. Since the length cannot always be determined at compile time, the constraint must be changed to prose. REFERENCES: ISO/IEC 1539:1991 (E) section 4.5 EDITS: Delete the second constraint following R435. Add the following paragraph after the constraints in 4.5. Each ac-value expression in the array-constructor must have the same type and type parameters. SUBMITTED BY: (Questions 1 and 2) L. R. Rolison in 120-LRR-1 (120.026) (Question 3) L. R. Rolison in X3J3/93-070 LAST SIGNIFICANT CHANGE: 1993-02-11 000030 HISTORY: Response to Questions 1 and 2 - 120-LJO-1 (120.074) Question 3. submitted as X3J3/93-070 at meeting 124 Complete proposed response in X3J3/93-100 adopted at meeting 124 by unanimous consent ----------------------------------------------------------------------- NUMBER: 000039 TITLE: Association of a Pointer Actual Argument with a Dummy Argument KEYWORDS: pointer, actual argument, dummy argument, argument association DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: When a pointer is passed as an actual argument, is the intent of the standard as follows: Dereferencing of the pointer is dependent on the interface of the called procedure. That is, if the dummy argument is known to be a pointer (with matching type, etc.) then the pointer actual argument is NOT dereferenced - the pointer itself is passed. Conversely, if the dummy argument is unknown or is known to not be a pointer then the pointer dummy argument is dereferenced so that its target is passed (possibly through a temporary)? If yes, please quote the text that specifies the meaning of passing a pointer as an actual argument. ANSWER: Section 5.1.2.4.3 indicates that a pointer actual argument may be associated with either a pointer dummy argument or a nonpointer dummy argument. The semantics of a pointer actual argument associated with a pointer dummy argument are specified in section 12.4.1.1. When a pointer actual argument is associated with a nonpointer dummy argument, the actual argument's associated target object becomes associated with the dummy argument. Section 7.1.4.1 states If a pointer appears as a primary in an intrinsic operation or a defined operation in which it corresponds to a nonpointer dummy argument, the associated target object is referenced. Discussion: The standard does not specify implementation details. A valid implementation would allow passing a descriptor when a pointer actual argument is associated with a pointer dummy argument and a temporary when the dummy argument is a nonpointer. Another valid implementation would be to pass a descriptor in both cases. Since the notion of referencing and dereferencing pointers is implementation dependent, the standard does not use these terms when discussing pointers and targets. The standard does state when a pointer's association status may change (pointer assignment, allocation, deallocation, nullification, and association with a dummy argument which is a pointer) and several cases where a pointer name refers to the associated target object (assignment as primary in an expression, and an I/O list). There is also an example of a pointer actual argument associated with a nonpointer dummy argument in section 12.5.2.9. The corrections indicated below clarify the rules and meaning of associating a pointer actual argument with a nonpointer dummy argument. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1.2.4.3, 7.1.41, 7.5.1.5, 9.4.4.4, 12.4.1.1, & 12.5.2.9 EDITS: 1. Delete the penultimate (tenth) paragraph of 5.1.2.4.3, "A pointer dummy argument ... argument." [46:41-42] 2. Add the following new paragraph following the current fifth paragraph of section 12.4.1.1: [173:13+] If the dummy argument is not a pointer and the corresponding actual argument is, the actual argument must be currently associated with a target and the dummy argument becomes argument associated with that target. SUBMITTED BY: L. R. Rolison, 120-LRR-9 (120.034) LAST SIGNIFICANT CHANGE: 1993-02-12 000039 HISTORY: 120-JLS-9 (120.079) Passed letter ballot to move to "Ready for WG5" status Revised response in 93-102 adopted at meeting 124 by unanimous consent ----------------------------------------------------------------------- NUMBER: 000041 TITLE: Procedure with Target Dummy Argument Requires Explicit Interface KEYWORDS: dummy argument, explicit interface, TARGET attribute DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: If a procedure has a dummy argument that has the TARGET attribute, it must have an explicit interface (section 12.3.1.1). The TARGET attribute is defined solely for the purpose of aiding optimization (C.5.3). Why must such a procedure have an explicit interface? ANSWER: Section C.5.3 is in error by stating the TARGET attribute is solely to aid optimization. It is true that requiring an explicit interface for a procedure with a dummy argument that has the TARGET attribute aids optimization of the subprogram that calls the procedure. Such an explicit interface also allows a processor to diagnose when an actual argument which does not have the TARGET attribute becomes associated with a dummy argument that has the TARGET attribute. The supplied edit corrects the error. Discussion: Section 6.3.3.2 states that upon execution of a RETURN or END statement, some pointers declared or accessed in the procedure retain their association status. For example, if a pointer is accessible to both the subprogram which references the procedure and the referenced procedure, or if the procedure is a function whose result has the POINTER attribute, such a pointer cannot become associated with an actual argument during execution of the procedure if the target actual argument becomes associated with a nontarget dummy argument. If a procedure does not have an explicit interface, a processor may assume any actual argument with the target attribute cannot become associated with such a pointer during execution of the procedure. Requiring an explicit interface for a procedure with a target dummy argument also allows the processor to diagnose association of a nontarget actual argument, such as an expression, with the target dummy argument. Note that edits in defect item 125 make the need for the explicit interface mandatory. REFERENCES: ISO/IEC 1539:1991 sections 6.3.3.2, 12.3.1.1, and C.5.3 EDIT: Section C.5.3, second sentence, change "solely" to "primarily". SUBMITTED BY: K. Kazumura, X3J3/92-048 (121-ADT-8) page 23 LAST SIGNIFICANT CHANGE: 1993-02-12 000041 HISTORY: Posted request to f90 interp e-mail Approved as X3J3/92-070 meeting 121 Approval rescinded at meeting 123 (uc) Revised response in X3J3/93-101 adopted at meeting 124 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000058 TITLE: Ambiguous use of "keyword" KEYWORDS: keyword, argument keyword DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Is the use of "keyword" in 12.4.1 page 172 1st paragraph consistent with the definition of "keyword" in 3.2.1, page 19? Is the definition of keyword in 3.2.1 consistent with the two definitions of keyword in 2.5.2 page 16? In 13.10 page 188 is "keyword" the correct term (or should it be "argument keyword")? ANSWER: For each question, the answer is "NO". There are two different definitions of "keyword", 2.5.2 page 16 and 3.2.1 page 19. Neither definition is complete. The edits below combine these two definitions into one and consistently use "argument keyword" where appropriate. Note that edits 3 and 6 are related to edit 1 in item 4. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.5.2, 3.2.1, 12.4.1,& 13.10 EDIT(S): 1. Page 5, section 1.5.3, (3) [5:9] delete "keyword actual arguments and" rationale: these are not specifiers and -spec is not used with them. 2. Page 16, section 2.5.2, first paragraph, first occurrence [16:3] change "statement keyword" --------- ------- to "statement keyword (often abbreviated to keyword)" --------- ------- ------- rationale: define "keyword", in a style similar to "object" in 2.4.3.1. 3. Page 16, section 2.5.2, first paragraph, end of [16:5] add "Keywords appear as upper-case words in the syntax rules in Sections 4 through 12". 4. Page 16, section 2.5.2, second paragraph, first sentence [16:6] change "name." to "name (see 12.4.1)." 5. Page 19, section 3.2 [19:35] change "keywords" to "statement keywords (2.5.2)" 6. Page 19, section 3.2.1 [19:37-38] delete rationale: 2.5.2 is now the complete definition. 7. Page 160, section 11.3.3.5, first paragraph, third line [160:29] change "keywords" to "argument keywords" 8. Page 168, the pp following the line "END INTERFACE", second sentence [168:24] replace with "Invocations of these procedures may use argument keywords; for example:" rationale: "keyword calls" is not defined. In general invocations can use both positional and argument keywords. 9. Page 172, 1st paragraph following constraints, 3 occurrences [172:13,16,17] change "a keyword" to "an argument keyword", two occurrences, and change "the keyword" to "the argument keyword" 10. Section 13.3, first sentence [183:37], set "positional arguments" and "keyword arguments" in regular font 11. Page 183, section 13.3, first paragraph, third line, 2 occurrences [183:38] change "the keyword" to "the argument keyword" and change "A keyword" to "An argument keyword" 12. Page 188, section 13.10, first paragraph, first two lines, 2 occurrences [188:12,13] change "keyword" to "argument keyword" and change "keywords" to "argument keywords" 13. Page 363, entry for "argument keywords 183" [363:37] delete rationale: odd to index both singular and plural. "Keyword", and "statement keyword" are indexed to p16, as is the remaining entry for "argument keyword". 14. Annex F, delete entry for "positional arguments" [368:13] SUBMITTED BY: GEN HISTORY: WG5/N808, Question 2. Approved as X3J3/92-164A at meeting 122 by a vote of 17-4 -------------------------------------------------------------------------- NUMBER: 000070 TITLE: Characteristics specified by interface bodies KEYWORDS: DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 12.3.2.2 indicates that an interface body specifies all of a procedure's characteristics and that the characteristics must be consistent with those in the procedure definition. Are the following code fragments standard conforming? (a) PROGRAM FRED INTERFACE SUBROUTINE SUB (ARR,J) INTEGER ARR(1:) END SUBROUTINE END INTERFACE INTEGER ARR(10) CALL SUB(ARR,2) END PROGRAM SUBROUTINE SUB(ARR, J) INTEGER ARR(J:) ... END SUBROUTINE SUB (b) FUNCTION C1( ) CHARACTER(*) C1 ... END FUNCTION C1 FUNCTION C2(N) CHARACTER(N) C2 ... END FUNCTION C2 SUBROUTINE CALLER( ) INTERFACE FUNCTION C1( ) CHARACTER(*) C1 END FUNCTION FUNCTION C2(N) CHARACTER(2) C2 END FUNCTION END INTERFACE CHARACTER(5) CC CC=C1( )//C2(2) ANSWER: (a) This example is standard conforming. (b) This example is not standard conforming. Discussion: (a) 12.2.1.1 states that the characteristics of a dummy data object include its shape, and that if the shape is assumed then that is a characteristic. Section 2.4.5 states that the shape of an array is determined by its rank and extent in each dimension (but not by its bounds, 5.1.2.4.2). Both the interface block for SUB and the definition of SUB describe the shape of ARR as assumed, so they are describing the same shape, and the program is standard conforming. It is possible to read the second sentence in 12.2.1.1 as requiring bounds to match. This was not intended. An edit is included to clarify that it is the shape resulting from the bounds specifications that is a characteristic and not the bounds themselves. (b) Section 12.2.2 states that the characteristics of a function include whether or not the function result value is a character of assumed length. So the interface body for function C1 must indicate that C1 is of assumed length. However, item (3) in 5.1.1.5 indicates that scoping units that invoke an external character function of assumed length must have access to a declaration of the function name with a length type parameter value other than *. An edit is included to clarify this restriction. In addition, the interface for C2 does not conform to the standard as the length of C2 specified as 2 is not consistent with the length specified as N within the function definition. EDITS: 1. In section 5.1.1.5 item (3), add to the end: "Note that the interface for such a function cannot be specified in an interface body." 2. Replace the last two sentences in 12.2.1.1 [166:4-6] with the following: If the shape or character length type parameter is not constant, the corresponding characteristic is the method by which the value is to be determined when the procedure is invoked. This includes the possibility that the value is assumed or that it is given by evaluating a specification expression. Two such methods are considered to be the same if they yield the same value under all possible conditions in which they might be applied; they need not be expressed identically. 3. Replace the last two sentences in 12.2.2 [166:14-16] with the following: If the shape or character length type parameter is not constant, the corresponding characteristic is the method by which the value is to be determined when the function is invoked. This includes the possibility that the value is assumed or that it is given by evaluating a specification expression. Two such methods are considered to be the same if they yield the same value under all possible conditions in which they might be applied; they need not be expressed identically. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.4.5, 5.1.1.5, 5.1.2.4.2, 12.2.1.1, and 12.2.2. SUBMITTED BY: Graham Barber (a), Janice Shepherd (b) LAST SIGNIFICANT CHANGE: 1992-11-11, new 000070 HISTORY: Question (a) originally posed in X3J3/92-264. Question (b) originally posed in e-mail collection X3J3/92-46. Response proposed in X3J3/92-283. Approved by unanimous consent at meeting 123. Response questioned by John Reid in X3J3/93-018. Revised response proposed in X3J3/93-103. Approved by unanimous consent at meeting 124. -------------------------------------------------------------------------- NUMBER: 000071 TITLE: USE association and COMMON block names KEYWORDS: use association, COMMON block names, storage association DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Can a module or subprogram access through USE association variables declared in different modules to be in the same common block? Example: MODULE MOD1 COMMON /BLOCK/ A,B,C END MODULE MOD1 MODULE MOD2 COMMON /BLOCK/ X,Y,Z END MODULE MOD2 SUBROUTINE USER() USE MOD1 USE MOD2 ... Y = A ! Are both Y and A accessible? END ANSWER: Yes. Discussion: The COMMON statement in MOD1 forms a common block storage sequence as described in 5.5.2.1. The COMMON statement in MOD2 similarly forms a common block storage sequence. These two sequences are associated as described in 5.5.2.3, thus associating A with X, B with Y, and C with Z. The USE statements in USER make these variables accessible in that scoping unit. The associated variables are considered to behave as though they had been EQUIVALENCEd. The list of entities made accessible by USE association in 11.3.2 includes variables but not common blocks, so there is no implication that these two specifications of common block storage sequences for /BLOCK/ interfere with each other or require a concatenated common block storage sequence in USER. Various other combinations of USE association, host association, and local COMMON statements can similarly result in common associated variables being accessible in the same scoping unit. One of these cases, that involve USE association and local COMMON statements, is prohibited in 5.5.2.5. The edits below emphasize the independence of common block storage sequence formation from USE and host association and eliminate the ineffective restriction in 5.5.2.5. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.5.2.1, 5.5.2.3, 5.5.2.5, and 11.3.2 EDITS: 1. In the first sentence of 5.5.2.1 after "For each common block", insert "in a scoping unit". 2. At the end of 5.5.2.1, add the following paragraph: "Only COMMON statements and EQUIVALENCE statements appearing in the scoping unit contribute to common block storage sequences formed in that unit. Variables in common made accessible by USE association or host association do not contribute." 3. At the end of the first paragraph of 5.5.2.3, add the following sentence: "USE association or host association may cause these associated objects to be accessible in the same scoping unit." 4. Delete the last two sentences in 5.5.2.5. SUBMITTED BY: Jon L. Steidel, 120-JLS-8 LAST SIGNIFICANT CHANGE: 1992-11-12, added edits to previously proposed interpretation 000071 HISTORY: 120-86 (120-MBSH-3), initial response draft 92-163, revised draft response 92-191, revised draft response 92-316, revised draft response - approved by a (19-2) vote at meeting 123 -------------------------------------------------------------------------- NUMBER: 000073 TITLE: Description of the MERGE intrinsic function KEYWORDS: elemental function, MERGE, array construction function DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTIONS: The MERGE intrinsic function is described as an array construction function in sections 13.8.6 and 13.10.16. The description of MERGE in section 13.13.67 classifies it as an elemental function. 1. Are the descriptions of MERGE in sections 13.8.6 and 13.10.16 consistent with its classification as an elemental function? Note that 13.8 is "Array intrinsic functions" and MERGE is the only elemental included. 2.Should all elemental functions be listed as "array construction" functions or should MERGE be described elsewhere. ANSWERS: 1.Yes. MERGE is both an elemental intrinsic function and, when called with array arguments, an array construction function. 2.All elemental intrinsic functions are array construction functions when called with array arguments. REFERENCES: ISO/IEC 1539:1991 (E) sections 13.8.6, 13.10.16, 13.13.67 EDIT: None SUBMITTED BY: Dick Weaver X3J3/92-197 LAST SIGNIFICANT CHANGE: 93-02-11 000073 HISTORY: Submitted as X3J3/92-197 Draft response in X3J3/92-322 at meeting 123 (not approved) Response in X3J3/93-090, passed 14-4 -------------------------------------------------------------------------- NUMBER: 000075 TITLE: Interface blocks in block data KEYWORDS: interface block, block data DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: In section 12.3.2.1, on page 167, the third constraint "An interface-block must not appear in a BLOCK DATA program unit" is constraining what? (The existence of a constraint implies that, if the constraint were not present, the constrained "action" would be allowed.) ANSWER: The constraint is redundant with the second constraint in section 11.4. REFERENCES: ISO/IEC 1539:1991 (E) sections 11.4, 12.3.2.1 EDIT: None SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 92-11-11, first draft response 000075 HISTORY: X3J3/92-200 Draft response in X3J3/92-323 at meeting 123, not approved -------------------------------------------------------------------------- NUMBER: 000079 TITLE: Automatic character and ALLOCATABLE, POINTER and TARGET attributes KEYWORDS: Allocatable, automatic, array, character, pointer, target DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 5.1 states: The specification-expr (7.1.6.2) of a type-param-value (5.1.1.5) or an array- spec (5.1.2.4) may be a nonconstant expression provided the specification expression is in an interface body (12.3.2.1) or in the specification part of a subprogram. If the data object being declared depends on the value of such a nonconstant expression and is not a dummy argument, such an object is called an automatic data object. An automatic object must not appear in a SAVE or DATA statement nor be declared with a SAVE attribute nor be initially defined with an = initialization-expr. Thus, a character object with a length-selector which is a nonconstant type- param-value is an automatic object. Section 5.1.2.9 states: The ALLOCATABLE attribute specifies that objects declared in the statement are allocatable arrays. Such arrays must be deferred-shape arrays whose shape is determined when space is allocated for each array by the execution of an ALLOCATE statement (6.3.1). The standard does not appear to prohibit allocatable arrays of automatic objects. Question 1: Is it the intent to allow allocatable arrays of automatic character? FUNCTION FRED (J) CHARACTER(LEN=J), DIMENSION(:), ALLOCATABLE :: CH ALLOCATE (CH(100)) Question 2: If allocatable arrays of automatic objects are allowed, is it correct to assume the array must not have the SAVE attribute? Question 3: Character length is part of a character entity's type and type parameters. Was it intended that character entities whose length is specified by a variable expression or a * (assumed length character) be allowed to also have the POINTER or TARGET attribute? The third constraint of Section 7.5.2 states The target must be of the same type, type parameters, and rank as the pointer. In general, there should be no problem with allowing the POINTER and TARGET attribute for automatic arrays. However, there is a problem if TARGET is intended to be allowed for automatic character, both scalar and arrays, where the length is specified by a variable expression. Character length is part of the type and type parameters, but where length is specified by a variable, the above constraint cannot be diagnosed at compile time. Was it the intent to allow the TARGET attribute on any automatic objects, only on automatic arrays except where character length is specified by a variable expression, or for no automatic objects? If the intent is to allow TARGET on all automatic objects, the above constraint must be relaxed as it cannot be detected at compile time. ANSWER: The intent of the standard is to prohibit pointers and allocatable arrays of character type whose length is specified by a variable expression. An edit is supplied to clarify this prohibition. Also, the third constraint of section 7.5.2 cannot be diagnosed at compile time for automatic character targets or targets that are character dummy arguments with assumed length and, therefore, is relaxed by one of the supplied edits. REFERENCES: ISO/IEC 1539:1991 sections 5.1, 5.1.2.9, and 7.5.2. EDITS: 1. Section 5.1, add to the list of constraints: "The POINTER and ALLOCATABLE attributes must not be specified for an automatic data object." 2. In the third constraint of section 7.5.2 delete ", type parameters,". Add at the beginning of the paragraph following the constraints of section 7.5.2, "The target must have the same type parameters as the pointer." SUBMITTED BY: Jon Steidel LAST SIGNIFICANT CHANGE: 1993-02-10 000079 HISTORY: Initially drafted as X3J3/92-206 with two possible responses 92-206b "Second Possibility" rejected at meeting 123 (9-9) 92-206b "First Possibility" rejected at meeting 123 (14-5) "Second Possibility" adopted at meeting 124 (14-2) -------------------------------------------------------------------------- NUMBER: 000082 TITLE: Host association, generic name KEYWORDS: DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the program fragment 1 INTERFACE F 2 FUNCTION X(Y) ... 3 CONTAINS ... 4 INTEGER F(10) 5 I = F(2) Reading in 12.1.2.2.1, Host association: Statement 4 defines F to be an object-name (item 5 in the list on page 164). Thus F is the name of a local entity and any entity of the host that has F as its nongeneric name is inaccessible (text following list on page 164). Therefore the generic name, F, in the host is accessible. With that, is F(2) in stmt 5 a reference to the generic name or to the array name? ANSWER: F(2) is a reference to the array name. Discussion: The rules in 12.1.2.2.1 are incomplete as they fail to address of a generic name in the host. An edit is included to supply the missing rules. Applied to this case, they indicate that the outer F is inaccessible because the inner F is nongeneric. REFERENCES: ISO/IEC 1539:1991 (E) sections 12.1.2.2.1, 14.1.2.3, and 14.1.2.4 EDIT: In 12.1.2.2.1, insert the following after the sentence containing the long numbered list: If the local entity is nongeneric, any entity of the host that has this name as its generic name is inaccessible. If the local entity is generic and an entity of the host has this name as its generic name, the versions of the host entity that are prohibited by 14.1.2.3 from being merged with the local entity are instead inaccessible. SUBMITTED BY: Richard Weaver LAST SIGNIFICANT CHANGE: 93 02 11, initial response 000082 HISTORY: Submitted as X3J3/92-235 Related question submitted in X3J3/92-209 Response proposed in X3J3/92-104. Approved by unanimous consent at meeting 124. -------------------------------------------------------------------------- NUMBER: 000086 TITLE: USE and Host Association KEYWORDS:Use, association, host, accumulating, generic interface, EXTERNAL DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Use association, 11.3.2 states The USE statement provides the means by which a scoping unit access named data objects, derived types, interface blocks, procedures, generic identifiers (12.3.2.1), and namelist groups in a module. Host association, 12.1.2.2.1 states An internal subprogram, a module subprogram, or a derived-type definition has access to the named entities from its host via host association. The accessed entities are known by the same name and have the same attributes as in the host and are variables, constants, procedures including interfaces, derived types, type parameters, derived-type components, and namelist groups. Question 1: Do use and host association access the same entities? What entities does each access? Question 2: For both use and host association, what entities are not accessed? Question 3: For host and use association, if the host or module referenced contains an EXTERNAL statement for ABC, is ABC an accessed entity that has the EXTERNAL attribute? Note that an EXTERNAL statement is not a "named entity" (the statement has no name) and the procedure named in the statement is not in the host or module (that is why the EXTERNAL statement). The answer to question 1 or 2 should also answer this question. Question 4: Given the following PROGRAM A MODULE M USE X USE Y CONTAINS SUBROUTINE B USE M is subprogram B associated in some way with X? What way? Note that A, the host of B, "accesses" entities in X by use association; the entities in X are not "in" B's host. Question 5: In the same example is subprogram B associated in some way with Y? What way? As with question 4 note that the entities in Y are "accessed" from M; the entities in Y are not in M and use association is to the entities "in the module". Question 6: Given the following: MODULE A ! level 1 host USE AA INTERFACE F ... CONTAINS SUBROUTINE B ! module subroutine, level 2 host USE BB INTERFACE F .... CONTAINS SUBROUTINE C ! internal subprogram USE CC INTERFACE F ... .... = F(X) ! an invocation of the generic name F and where modules AA, BB, and CC all contain a generic interface for f: How is the invocation of the generic name F resolved? (in what sequence are which hosts and uses considered?) Note the levels of nesting: A contains B contains C. Section 14.1.2.4.1, "Resolving procedure references to names established to be generic", (3), seems to consider only B, the host of C, and not A. ANSWER: Answer 1:Entities declared PRIVATE are potentially accessible by host association but not by use association. Otherwise, it was intended that the classes of entities made accessible by these two forms of association be the same. These are named data objects (including both constants and variables), derived types derived type components, procedures (both those defined in the host or module and those declared there and defined elsewhere; both those identified by names and those identified by other generic identifiers), and namelist groups. See sections 12.1.2.1 and 11.3.2. An edit is provided to make the cited text consistent. Answer 2: Entities not in the list in 12.1.2.1 and 11.3.2 are not made accessible. For example, FORMAT statement labels, construct names, and common block names are not made accessible. Answer 3: In such an example, ABC would be accessible. Section 12.3.2.2 indicates that the EXTERNAL statement specifies a list of names that are procedures. In the host or module, ABC is the name of a procedure and thus is potentially an accessible entity; it is not necessary that the definition of ABC be present in the host or module. Answer 4: The entities of module X made accessible in A by use association are made accessible in B by host association. Note that each such entity has a local name (or other identifier) in A. See Section 11.3.2. Answer 5: The entities of module Y made accessible in M by use association are made accessible in B by use association. Note that each such entity has a local name (or other identifier) in M. See Section 11.3.2. Answer 6: In effect, first C and CC are checked for a consistent specific interface , then B and BB, then A and AA, and finally (if F were the generic name of an intrinsic function) the intrinsics are checked. In applying 14.1.2.4.1 to a reference in C, item (1) provides the check of interfaces in C (including those made accessible from cc), and item (3) provides for a recursive application of 14.1.2.4.1 to b. In this recursive application, (1) checks B (and BB), and (3) results in a further recursive application of 14.1.2.4.1 to A. In this application, (1) checks A (and AA), (3) is not applicable, and (4) checks the intrinsics. 14.1.2.3 establishes that there must be no ambiguity in distinguishing the interfaces declared in C from those made accessible from CC. REFERENCES: ISO/IEC 1539:1991 (E) sections 11.3.2, 12.1.2.2.1, 14.1.2.3, and 14.1.2.4.1. EDIT: In section 12.1.2.2.1 replace the second sentence of the first paragraph with: The accessed entities are known by the same name and have the same attributes as in the host and are named data objects, derived types, derived type components, interface blocks, procedures, generic identifiers (12.3.2.1), and namelist groups. SUBMITTED BY: Richard Weaver LAST SIGNIFICANT CHANGE: 1992-11-10, new 000086 HISTORY: Submitted in X3J3/92-214 Response proposed in 92-281 - meeting 123 (vote of 11-7 was insufficient for approval) Revised response proposed in 93-030r1. Approved at meeting 124 by a vote of (15-1) -------------------------------------------------------------------------- NUMBER: 000087 TITLE: PARAMETER statements and SAVE statements KEYWORDS: PARAMETER, named constant, SAVE DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Can a named constant appear in a SAVE statement? In Fortran 77 named constants were not allowed to appear in a SAVE statement. Fortran 90 appears to allow named constants in SAVE statements. ANSWER: No, a named constant must not appear in a SAVE statement. Edits are provided to indicate this restriction. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1, 5.1.2.5 EDITS: 1. Change the sixteenth constraint of section 5.1 to The SAVE attribute must not be specified for an object that is in a common block, a dummy argument, a procedure, a function result, an automatic data object, or an object with the PARAMETER attribute. 2. Change the penultimate sentence of 5.1.2.5 from "The SAVE attribute ... result, or an automatic data object." to "The SAVE attribute ... result, an automatic data object, or an object with the PARAMETER attribute." SUBMITTED BY: Janice C. Shepherd 93-011 LAST SIGNIFICANT CHANGE: 1993-02-10 000087 HISTORY: Submitted as 93-011 with proposed response After minor edits, adopted by unanimous consent at meeting 124 -------------------------------------------------------------------------- NUMBER: 000089 TITLE: Errors in the DATA statement description KEYWORDS: DATA statement, structure constructor, named constant, constant DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Does the text description in section 5.2.9 [53:4-20] of the values permitted in a DATA statement contain a recurring flaw? This description continually refers to the constant values in the list as simply "constants". According to R533 a structure constructor is allowed in the list, but it is not a constant; rather it is a constant expression. This is demonstrated by: The definition of "constant" in 2.4.3.1.2. There are only two broad categories of constants defined: named constants and literal constants. The syntax rules for "constant" (R305-R307) reinforce this definition by defining only two nonterminals: literal-constant and named-constant. The description of the structure constructor in section 4.4.4 [37:10-11] states: A structure constructor whose component values are all constant expressions is a derived-type constant expression. ANSWER: Yes, there is a flaw in Section 5.2.9 in the text description of the values permitted in a DATA statement. The following edits eliminate this flaw. Discussion: In considering the edits to Section 5.2.9 to repair this flaw, it became apparent that the second sentence in the third paragraph following the constraints, [53:4-5] REach such value ... host association.S applied equally to named constants and structure constructors. This means that the type definition for the structure constructor must be accessible. Furthermore, this should be stated as a constraint. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.2.9, 2.4.3.1.2, 3.2.3, 4.4.4 EDITS: 1. Add a new constraint after the second constraint following R537: If a DATA statement constant value is a named constant or a structure constructor, the named constant or derived type must have been declared previously in the scoping unit or made accessible by use or host association. 2. Delete the second sentence in the third paragraph following the constraints [53:4-5], REach such value ...host association.S 3. In the third sentence [53:6], replace Rfollowing constantS with Rfollowing constant valueS. 4. In the next two paragraphs [53:11, 17], change RconstantS to Rconstant valueS (twice) 5. In the sixth paragraph [53:18, 19], change RconstantS to Rconstant or structure constructorS (twice) SUBMITTED BY: Larry Rolison - X3J3/92-221 LAST SIGNIFICANT CHANGE: 1993-02-10 000089 HISTORY: Submitted as X3J3/92-221 at Meeting 123 Draft response X3J3/93-032 prepared for consideration at Meeting 124 Revised as X3J3/93-032r1 based on comments from Rolison and adopted at meeting 124 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000091 TITLE: Constraint diagnosis for PRIVATE attribute KEYWORDS: PRIVATE, modules, constraints DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Must the violation of constraints be diagnosed when the criteria for the constraint is violated or confirmed across module definitions? More specifically should the following two constraints: The third constraint following R522: [49:26-28] A module procedure that has a dummy argument or function result of a type that has PRIVATE accessibility must have PRIVATE accessibility and must not have a generic identifier that has PUBLIC accessibility. The fourth constraint following R424: [33:10-11] 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. be diagnosed in the following program?: MODULE A TYPE X INTEGER :: I END TYPE X TYPE Y TYPE (X) :: R ! Note component of type X END TYPE Y CONTAINS FUNCTION F() ! Module function of type X TYPE(X) :: F END FUNCTION F END MODULE A MODULE B USE A PRIVATE :: X ! Note component of type Y now has ! a PRIVATE attribute ! Note also that module function F now ! has PRIVATE attribute END MODULE B ANSWER: Yes Discussion: Module A by itself is standard-conforming. It is not until module A is used by module B that the cited constraints are violated. REFERENCES: ISO/IEC 1539:1991 (E) sections 1.4, 4.4.1, and 5.2.3 SUBMITTED BY: Maureen Hoffert LAST SIGNIFICANT CHANGE: 1993-02-10 00091 HISTORY: Submitted at 123 in X3J3/92-225. Response in X3J3/93-024 adopted at meeting 124 by a vote of (14-3) -------------------------------------------------------------------------- NUMBER: 000092 TITLE: Pointer and Storage Association KEYWORDS: pointer association, storage association, ASSOCIATED DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following example program: PROGRAM PROG INTEGER :: VAR COMMON /COM/ VAR VAR = 5 CALL SUB END PROGRAM PROG SUBROUTINE SUB INTEGER,POINTER :: PTR INTEGER,TARGET :: TGT COMMON /COM/ TGT PTR => TGT ... END SUBROUTINE SUB Is the pointer assignment legal? Although the entity named TGT was declared with the TARGET attribute, a storage associated entity, VAR, was not. ANSWER: The pointer assignment is legal only because PTR is declared within the scoping unit of SUB and is not accessible outside the scoping unit of SUB. Discussion: By the rules of 6.3.3.2, PTR becomes undefined upon return from SUB to the calling program. Note however that if PTR was also accessible in the scoping unit PROG and the variable VAR was not declared with the TARGET attribute, the program would not be standard conforming. The following example is not standard conforming. PROGRAM PROG INTEGER :: VAR INTEGER,POINTER :: PTR COMMON /COM/ VAR, PTR VAR = 5 CALL SUB ... END PROGRAM PROG SUBROUTINE SUB INTEGER,POINTER :: PTR INTEGER,TARGET :: TGT COMMON /COM/ TGT, PTR PTR => TGT ... END SUBROUTINE SUB After the call to SUB, PTR is pointer associated with the same storage that VAR is storage associated with. In this case, VAR must be declared with the TARGET attribute in the scoping unit PROG for the program to be standard conforming. REFERENCES: ISO/IEC 1539:1991 (E) section 6.3.3.2. EDITS: None. SUBMITTED BY: Len Moss LAST SIGNIFICANT CHANGE: 1993-02-10 000092 HISTORY: Issue arose during Victoria (1992) WG5 meeting, while reviewing various questions concerning S20.121(27) Separate request submitted following meeting 121 Submitted as X3J3/92-226 at meeting 123 Response in X3J3/93-035 adopted at meeting 124 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000093 TITLE: Scalar Pointer Function Results KEYWORDS: function results, pointer attribute DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: May a scalar function result have the pointer attribute? ANSWER: Yes. Discussion: The text that appears as the last paragraph of 5.1.2.4.3 is intended to apply to all function results even though it appears in a section titled, "Deferred-shape array". To clarify this point, the edit below moves that text to section 5.2 which has the more general title, "Type declaration statements". REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1 and 5.1.2.4.3 EDIT: Delete the last paragraph of 5.1.2.4.3 [46:43]. Insert the following paragraph after the second paragraph following the constraints in 5.1 [40:38+] A function result may be declared to have the pointer attribute. SUBMITTED BY: Len Moss - X3J3/92-227 LAST SIGNIFICANT CHANGE: 1993-02-10 000093 HISTORY: Submitted as X3J3/92-227 at meeting 123 Proposed response in X3J3/93-075 adopted at meeting 124 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000097 TITLE: Specification Expression KEYWORDS: constant expression, specification expression DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTIONS: In section 7.1.6.2 "Specification expression": 1. In item (9) should not the restriction "defined by an ALLOCATE statement" be "allocatable" instead? That is, the ALLOCATE statement does not have to exist, it is being allocatable -- even if never allocated -- that is restricted. [79:14-15] And the same comment re pointer assignment. [79:14-15] 2. Would Item (9) be clarified if "local" were inserted before "variable"? [79:14] 3. In the text beginning "and where any subscript ..." should not "is" be "must be"? As written it says that any subscript is a restricted expression. [79:17] 4. In the text beginning "A specification expression (R509, R514, R515)... should not the "(R509, R514, R515)" be deleted? ANSWER: 1. Yes, see edits below. Edits are provided for similar problems in other sections. 2. No. 3. No, this is part of a long and complex sentence which begins on the previous page. 'Is' is the correct form and parallels the rest of the sentence and describes what a restricted expression 'is', not what a subscript is. 4. There is redundancy, but not an error. REFERENCES: ISO/IEC 1539:1991 (E) sections 7.1.6.1, 7.1.6.2 EDITS: Replace 7.1.6.1 (6), in the first list, with the following: (6) A reference to a) an array inquiry function (13.10.15) other than ALLOCATED b) the bit inquiry function BIT_SIZE, c) the character inquiry function LEN, d) the kind inquiry function KIND, e) or a numeric inquiry function (13.10.8) where each argument of the function is either a) a constant expression b) a variable whose type parameters or bounds inquired about are not assumed, c) or a variable that does not have the ALLOCATABLE or POINTER attribute, or Replace 7.1.6.1 (6), in the second list with the following: (6) A reference to a) an array inquiry function (13.10.15) other than ALLOCATED b) the bit inquiry function BIT_SIZE, c) the character inquiry function LEN, d) the kind inquiry function KIND, e) or a numeric inquiry function (13.10.8) where each argument of the function is either a) an initialization expression b) a variable whose type parameters or bounds inquired about are not assumed, c) or a variable that does not have the ALLOCATABLE or POINTER attribute, or Replace 7.1.6.2 (9) with the following: (9) A reference to a) an array inquiry function (13.10.15) other than ALLOCATED b) the bit inquiry function BIT_SIZE, c) the character inquiry function LEN, d) the kind inquiry function KIND, e) or a numeric inquiry function (13.10.8) where each argument of the function is either a) a restricted expression b) a variable whose type parameters or bounds inquired about are not assumed, c) or a variable that does not have the ALLOCATABLE or POINTER attribute, or SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 92-11-11 000097 HISTORY: Submitted as X3J3/92-233r at meeting 123 -------------------------------------------------------------------------- NUMBER: 000100 TITLE: ASSOCIATED intrinsic and zero-sized objects KEYWORDS: Associated, Zero sized objects, Target, Pointer DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The response to defect item 000027 states what conditions must be met for the two argument form of the ASSOCIATED intrinsic function to return a value of true. It does not state what the behavior of the intrinsic is for zero sized arguments. Question 1: Can the single argument form of the ASSOCIATED intrinsic return true as its result if the argument's target is zero sized? Question 2: Can the two-argument form of the ASSOCIATED intrinsic return true when both arguments are zero sized? The following need answers only if the answer to question 2 is yes. Question 2a: If the arguments to ASSOCIATED are zero sized but of rank greater than one, must the extents of each dimension be the same for ASSOCIATED to return true? For example, what is printed by the following program? PROGRAM HUH REAL, DIMENSION(:,:), POINTER :: P1, P2 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(10:9:1, :) P2 => A(:, 10:9:1) PRINT *, ASSOCIATED (P1, P2) END Question 2b: In the following example, rank, shape, type, kind type parameters, and extent of dimensions of the zero sized arguments to ASSOCIATED match, but the second argument is not the same as the right hand side of the previous pointer assignment statement. What is the output of this program? (Does a notion of "base address" come to play for zero-sized objects as it does for nonzero-sized objects?) PROGRAM HMMM REAL, DIMENSION(:,:), POINTER :: P1 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(:, 2:1:1) PRINT *, ASSOCIATED (P1, A(:, 3:2:1)) END ANSWER: The one-argument form of ASSOCIATED is intended to return a result of true if the pointer actual argument is currently associated with a target, even if the target is zero sized. The result of the two-argument form of the ASSOCIATED function is undefined if either of the arguments is a pointer that is currently associated with a target that is zero sized or if the second argument is not a pointer but of zero size. The following edits clarify the intent. REFERENCES: ISO/IEC 1539 : 1991 section 13.13.13. EDITS: 1. Section 13.13.13 Case (ii) add the following sentence at the end If POINTER is currently associated with a zero-sized target, or TARGET is a zero-sized array, the result is undefined. 2. Section 13.13.13 Case (iii) add the following sentence after the last sentence. If either POINTER or TARGET are associated with a zero-sized array, the result is undefined. SUBMITTED BY: Jon Steidel - X3J3/92-240 LAST SIGNIFICANT CHANGE: 1993-02-10 000100 HISTORY: Submitted as X3J3/92-240 at meeting 123 Response in X3J3/93-034r1 adopted (with edits) at meeting 124 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000105 TITLE: Parallel Evaluation of Operands and Arguments KEYWORDS: expression, operand, argument, function, parallel, concurrent DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Question 1 Does Fortran permit concurrent evaluation of operands in expressions and of actual arguments of functions? Question 2 Is the following program standard conforming? PROGRAM TEST INTEGER F,M PRINT *, F(1,M) + F(2,M) END FUNCTION F(X,M) INTEGER F,X,M M = X*X F = M+M RETURN END ANSWER: Answer 1 Yes, the standard permits a wide variety of expression evaluation models. Answer 2 No, the specific example provided is not standard conforming. Discussion: Sections 7.1.7.1, 12.4.2 and 12.5 provide information on rules for expression evaluation and argument association. Annex C section 12.5 attempts to make it clear what was intended. The use of concurrent, parallel or lazy evaluation of expressions is permitted in a standard conforming Fortran processor. Any program whose results depend on how expression evaluation is performed is not standard conforming. In the example provided in the question the PRINT statement is non-standard conforming. Section 7.1.7 contains the following prohibition: The evaluation of a function reference must neither affect nor be affected by the evaluation of any other entity within the statement. REFERENCES: ISO/IEC 1539:1991 (E) Sections 7.1.7, 12.4.2,12.5, C.12.5 SUBMITTED BY: R. L. Page LAST SIGNIFICANT CHANGE: 93 Feb. 000105 HISTORY: Contributions to the discussion provided by Brian Smith Type changed from Amendment to Interpretation meeting 124 in 93-079r1. Approved by unanimous consent at meeting 124. -------------------------------------------------------------------------- NUMBER: 000106 TITLE: Multiple USE of modules; renaming rules KEYWORDS: USE, modules, accessibility, renaming DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Section 11.3.2 states 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, all public entities in the module are accessible and the rename-lists and only-lists are interpreted as a single concatenated rename-list. If all the USE statements have ONLY qualifiers, only those entities named in one or more of the only- lists are accessible, that is, all the only-lists are interpreted as a single concatenated only-list. Assume the following module definition in considering the following questions. MODULE MOD INTEGER I, J, K END MODULE Question 1: If the following USE statements appear in a scoping unit, by what names are I and J accessible? USE MOD USE MOD, ONLY: X => I USE MOD, ONLY: Z => J The rules quoted above state in this case all public entities are accessible since one of the USE statements is without an ONLY qualifier. By concatenating the only-lists and rename-lists on a single rename list we have USE MOD, X => I, Z => J Is I accessible through both the name I and X, and is J accessible through both the name J and Z? Question 2: Same as question 1 without the ONLY clause. Here, all the USE statements are without ONLY clauses. USE MOD USE MOD, X => I USE MOD, Z => J Because MOD appears in a USE statement without a rename-list, are all public entities from MOD accessible by their declared name in MOD as well as any local names given in the rename-lists? That is, is I accessible by both I and X, and J accessible by both J and Z? ANSWER: In both examples, I is made accessible only as X, and J is made accessible only as Z. Discussion: The text cited in 11.3.2 allows a collection of USE statements referencing the same module to be interpreted as an equivalent single USE statement. This circumvents restrictions on list lengths that would otherwise be indirectly imposed by the source form rules on line lengths and number of continuations. In general, it is not possible to characterize the effect of such a collection as the union of the effects that each individual statement would have in the absence of the other statements. USE statements with ONLY: can be so composed but not USE statements without ONLY:, because the lists on other USE statements can limit the accessibility of entities not explicitly named in a USE statement without ONLY:. There are programming practices that can minimize the confusion this might engender: Use of multiple USE statements referencing the same module can be limited to those cases where it is required by the length of the list involved. When multiple USE statements are required, a minimum number can be used, and they can be placed one after another. If one USE statement indicates that all public entities are to be accessible (by omitting ONLY:), all can do so. The standard does not require any of these programming practices. REFERENCES: ISO/IEC 1539:1991, section 11.3.2 EDIT: None. SUBMITTED BY: Jon Steidel LAST SIGNIFICANT CHANGE: 1993-02-10, expanded discussion 000106 HISTORY: Initially drafted as X3J3/92-246 Response proposed in X3J3/92-279 meeting 123 vote (12-4) insufficient to approve Discussion section expanded in X3J3/93-106. Approved by a vote of (14-2) at meeting 124. -------------------------------------------------------------------------- NUMBER: 000108 TITLE: Referencing disassociated pointers KEYWORDS: pointer, target, association status, dissasociated, array pointer, inquiry functions, referenced, defined DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: There are several places in the standard that refer to whether a disassociated pointer can be referenced. The places seem to be inconsistent in the restrictions they place on such references. In section 5.1.2.4.3 "The size, bounds, and shape of the target of a disassociated array pointer are undefined. No part of such an array may be defined, nor may any part of it be referenced except as an argument to an intrinsic inquiry function that is inquiring about argument presence, a property of the type or type parameters, or association status." In section 5.2.7 "An object that has the POINTER attribute must not be referenced or defined unless, as a result of executing a pointer assignment (7.5.2) or an ALLOCATE statement (6.3.1), it becomes pointer associated with a target object that may be referenced or defined." In section 7.1.4.1 "If the pointer is not associated with a target, it may appear as a primary only as an actual argument in a reference to a procedure whose corresponding dummy argument is declared to be a pointer." In section 7.5.2 "A pointer must not be referenced or defined unless it is associated with a target that may be referenced or defined." In section 13.7.2 "The inquiry functions RADIX, DIGITS, MINEXPONENT, MAXEXPONENT, PRECISION, RANGE, HUGE, TINY, and EPSILON return scalar values related to the parameters of the model associated with the types and kind type parameters of the arguments. The value of the arguments to these functions need not be defined, pointer arguments may be disassociated, and array arguments need not be allocated." (1) Where exactly can a pointer that is disassociated be referenced? (2) Can array pointers that are disassociated be referenced in more places than scalar pointers that are disassociated? (3) Can a pointer with an undefined association status ever be referenced? (eg as the argument to the KIND intrinsic in a PARAMETER statement). ANSWER: (1) A pointer that is disassociated may never be referenced. The text cited from 5.1.2.4.3 is misleading and the text cited from 13.7.2 is incomplete. With the edits below, the text becomes more precise. (2) No. (3) No. A pointer with undefined association status may be the argument to the KIND intrinsic in a PARAMETER statement, but this is not considered to be a reference. The term reference is defined in the first paragraph of section 6. Discussion: The first paragraph of section 6 defines a reference to be the appearance of a data object name or subobject designator in a context that requires its value. When a pointer appears as an argument to an inquiry intrinsic function that is inquiring about argument presence, a property of the type or type parameters, or association status, its value is not required. Thus a disassociated pointer may appear in these places. A pointer with undefined association status may appear in all of these places except as an argument to the ASSOCIATED intrinsic function. REFERENCES: ISO/IEC 1539:1991 (E) Sections 5.1.2.4.3, 5.2.7, 6, 7.1.4.1, 7.5.2, 13.7.2 EDITS: 1. Replace the text in the seventh paragraph of 5.1.2.4.3, "The size, bounds, and shape of the target ... association status." [46:25-33] with, "The size, bounds, and shape of the target of a disassociated array pointer are undefined. No part of such an array may be referenced or defined; however, the array may appear as an argument to an intrinsic inquiry function that is inquiring about argument presence, a property of the type or type parameters, or association status." 2. Replace the text in section 13.7.2 with, "The inquiry functions RADIX, DIGITS, MINEXPONENT, MAXEXPONENT, PRECISION, RANGE, HUGE, TINY, and EPSILON return scalar values related to the parameters of the model associated with the types and kind type parameters of the arguments. The value of the arguments to these functions need not be defined, pointer arguments may have undefined or disassociated association status, and array arguments need not be allocated." SUBMITTED BY: Janice C. Shepherd - X3J3/92-258 LAST SIGNIFICANT CHANGE: 1993-02-10 000108 HISTORY: Submitted as X3J3/92-258 at meeting 123 Response in 93-076 adopted at meeting 124 by a vote of (11-3) -------------------------------------------------------------------------- NUMBER: 000112 TITLE: Sequence Derived Type External Functions KEYWORDS: SEQUENCE, derived type, external functions DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Can an external function of sequence derived type be declared with a TYPE specification in the FUNCTION statement? For example, is the following a valid code fragment? TYPE (T) FUNCTION F () TYPE T SEQUENCE INTEGER I, J END TYPE T ... END ANSWER: Yes, the code fragment is valid, as an external function of sequence derived type can be declared with a TYPE specification in its FUNCTION statement. Discussion: The second paragraph of 12.5.2.2 indicates the only two conditions under which the attributes of a function result must be specified by specification statements within the function body. "If the function result is array-valued or a pointer, this must be specified by specifications of the name of the result variable within the function body." It was not intended that the syntax of allowing TYPE on a FUNCTION statement be limited to internal and module functions. The last sentence of the first paragraph of 5.1.1.7 should not be applied to function results. An edit is included for clarification. REFERENCES: 5.1.1.7, 12.5.2.2. EDIT(S): Add after the last sentence of the first paragraph of 5.1.1.7: "If the data entity is a function result, the derived type can be specified on the FUNCTION statement providing the derived type is defined within the body of the function or is accessible there by use or host association." SUBMITTED BY: Janice C. Shepherd, 92-130. LAST SIGNIFICANT CHANGE: Nov. 1992, original draft response 000112 HISTORY: Draft response proposed in 92-298 (14-4) vote at meeting 123 insufficient for approval Approved by unanimous consent at meeting 124. -------------------------------------------------------------------------- NUMBER: 000113 TITLE: Ordering of Array Specification and Initialization KEYWORDS: statement ordering, type declaration statement, initialization, shape, DIMENSION statement, attribute specification DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Fortran 90 requires that an array initialized via a DATA statement must have its array properties established by a previous specification expression (5.2.9). When an array is initialized via an =initialization-expr specification in a type declaration statement, however, there is no such requirement. For example, the code fragment, INTEGER :: I DATA I /2*1/ DIMENSION :: I(2) is prohibited by the standard, whereas the similar fragment, INTEGER :: I = (/1,1/) DIMENSION :: I(2) appears to be permitted. Is the lack of such a requirement when initializing an array in a type declaration statement an error in the standard? ANSWER: Yes, it was the intent of the committee that specifications in type declaration statements have the same restrictions as specifications in attribute specification statements. Discussion: Section 5.2 states, "The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification." Section C.5.1 also supports this intent. Thus there is evidence in the standard that the same restrictions should be applied to objects independent of whether their attributes were specified in a type declaration statement or an attribute specification statement. The edit below clarifies this intent for the initilization of arrays. REFERENCES: ISO/IEC 1539:1991 sections 5.1, 5.2, 5.2.9, and C.5.1 EDIT: Section 5.1, add the following to the end of the fifth paragraph following the constraints, "If the variable is an array, it must have its shape specified either in the type declaration statement or a previous attribute specification statement in the same scoping unit." SUBMITTED BY: Peter Griffiths LAST SIGNIFICANT CHANGE: 1993-02-11 000113 HISTORY: Initially drafted as X3J3/120-62 (120-LJM-2a) Resubmitted as X3J3/92-287 Response in X3J3/92-287r rejected at meeting 123 (8-12) Resubmitted with opposite answer at meeting 124 in 93-80 and adopted by a vote of (15-1) -------------------------------------------------------------------------- NUMBER: 000117 TITLE: Use of MODULE PROCEDURE Statement in Internal Procedures KEYWORDS: interface block, module procedure, host association DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The second constraint in section 12.3.2.1 appears to indicate that the following program fragment is not standard conforming. Is the following code fragment standard conforming? MODULE MOD CONTAINS SUBROUTINE SUB1(I) ... END SUBROUTINE SUB1 END MODULE PROGRAM MAIN USE MOD CALL INNER CONTAINS SUBROUTINE INNER INTERFACE SUB MODULE PROCEDURE SUB1 END INTERFACE ... END SUBROUTINE END PROGRAM ANSWER: Yes. The program fragment is standard conforming. Discussion: There are several defects in the second constraint of section 12.3.2.1. First, the constraint should not restrict the program fragment that is shown nor similar ones involving generic interfaces in internal procedures within module subprograms. Second, the constraint implies that an is a scope, when it is not. An edit is included to correct these defects. REFERENCES: ISO/IEC 1539:1991 (E) Section 12.3.2.1. EDIT: Replace the second constraint in section 12.3.2.1 with "The MODULE PROCEDURE specification is allowed only if the has a and is contained in a scoping unit where each is accessible as a module procedure." SUBMITTED BY: Y. Yoshida LAST SIGNIFICANT CHANGE: 1992-11-12, new 000117 HISTORY: Question posed in X3J3/92-132 items 63,64. Response proposed in X3J3/92-318; not formally considered at meeting 123 due to a lead time problem -------------------------------------------------------------------------- NUMBER: 000123 TITLE: Result of INT(A) not equal to A for non-default integers KEYWORDS: INT DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Is the sentence in 13.13.47 [pg 212, line 25] "case (i): If A is of type INTEGER, INT(A)=A" incomplete? Specifically consider the case of A being non-default INTEGER kind where RANGE(A) > RANGE(INT(A)) ANSWER: No, the sentence is complete. Discussion: Case(i) does not apply when RANGE(A) > RANGE(INT(A)) as the text just before the example addresses such cases: "The result is undefined if the processor cannot represent the result in the specified integer type" REFERENCES: ISO/IEC 1539:1991 (E) Section 13.13.47 SUBMITTED BY: JIS X3J3/93-036(3) LAST SIGNIFICANT CHANGE: 93 Feb, new 000123 HISTORY: Question posed in 93-036 item 3. Response proposed in 93-077. Approved by unanimous consent at meeting 124. -------------------------------------------------------------------------- NUMBER: 000125 TITLE: Copy in/ Copy out of Target Dummy Arguments KEYWORDS: Dummy Argument, Target, Explicit Interface, Association DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Previous Fortran standards have permitted copy in/ copy out as a valid implementation for argument passing to procedures, as does Fortran 90. Fortran 90 introduces pointer and target attributes. Sections 12.4.1.1 and C.12.8 indicate that it was intended that copy in/ copy out also be a valid implementation for passing dummy arguments that have the target attribute. The following example demonstrates a case where a copy in/ copy out implementation may get different results from an implementation which does not use a copy in/ copy out method for passing arguments that have the target attribute. POINTER IPTR TARGET I IPTR => I CALL SUB (I, IPTR) ... CONTAINS SUBROUTINE SUB (J, JPTR) POINTER JPTR TARGET J PRINT *, ASSOCIATED (JPTR, J) END SUBROUTINE END Is this a flaw in the standard? ANSWER: Yes, there is a flaw in the standard. The edits supplied disallow copy in/ copy out as a valid implementation for passing dummy arguments that have the TARGET attribute. Discussion: The changes apply only to target dummy arguments. Note that the edits supplied reinforce the response to defect item 41. REFERENCES: ISO/IEC 1539:1991 (E) sections 6.3.3.2, 12.4.1.1, and C.12.8. EDITS: 1. Add another item to list in section 6.3.3.2, "(7) An actual