From jwagener@amoco.com Thu Feb 25 09:07:49 1993 Received: from interlock.amoco.com by dkuug.dk with SMTP id AA17293 (5.65c8/IDA-1.4.4j for ); Thu, 25 Feb 1993 22:07:53 +0100 Received: by interlock.amoco.com id AA12624 (InterLock SMTP Gateway 1.1 for SC22WG5@dkuug.dk); Thu, 25 Feb 1993 15:00:44 -0600 Received: by interlock.amoco.com (Internal Mail Agent-2); Thu, 25 Feb 1993 15:00:44 -0600 Received: by interlock.amoco.com (Internal Mail Agent-1); Thu, 25 Feb 1993 15:00:44 -0600 Date: Thu, 25 Feb 93 15:07:49 CST Message-Id: <9302252107.AA10614@trc.amoco.com> From: Jerrold L. Wagener To: SC22WG5@dkuug.dk Subject: X3J3/93-006r ballot, part 1 of 2 X-Charset: ASCII X-Char-Esc: 29 ###################################################################### # # # X3J3/93-006r # # # # 1993 March 1-31 Letter Ballot # # # ###################################################################### 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 2 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 Continuation3 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 Argument 2 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 and generic names 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 is "X3J3 consideration in progress" status 2 is "X3J3 draft response" (these are the only items on this ballot) status 3 is "X3J3 approved; ready for WG5" ============================================================== 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. 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: 000012 TITLE: Type of a Named Constant when there is IMPLICIT Mapping KEYWORDS: named constant, parameter statement, IMPLICIT mapping, internal procedure, host DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: 1. Is the following code fragment valid Fortran 90? PARAMETER (A=1) IMPLICIT INTEGER (A) 2. Is the following code fragment valid? PROGRAM MAIN IMPLICIT INTEGER (Z) ! Z is mapped to type integer ... CONTAINS SUBROUTINE INNER PARAMETER (ZERO = (0.0, 0.0)) ! Name starts with Z IMPLICIT COMPLEX (Z) ! Z is mapped to type complex ... END SUBROUTINE END PROGRAM ANSWER: No in both cases. Discussion: In any scoping unit there is only one (possibly null) implicit typing map (5.3). Section 5.2.10 states that a named constant either must have its type, shape, and any type parameters specified previously or determined by the implicit typing rules currently in effect for the scoping unit. The word "currently" is intended to mean that any IMPLICIT statement which would affect the named constant must occur previously in the scoping unit. A subsequent IMPLICIT statement may specify the type of a named constant appearing in a PARAMETER statement, but in that case, it must confirm the type of the named constant. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.2.10 & 5.3 EDIT(S): None. SUBMITTED BY: (Question 1) J. T. Martin, 120-JTM-9 (120.046), question 3 (Question 2) J. L. Steidel, 120-JLS-2 (120.020) case 3 LAST SIGNIFICANT CHANGE: 1993-02-11 000012 HISTORY: 120-LJM-5 (120-093) X3J3/92-172, as modified, passed at meeting 122 Items 000012 and 000023 combined following letter ballot as X3J3/93- 73r2 and adopted at meeting 124 by unanimous consent ----------------------------------------------------------------------- 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 draft 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: 1993,-02-12, revised 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 93-087, consideration of ballot response: 92-316 reapproved by unanimous consent -------------------------------------------------------------------------- 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 92-323 reconsidered at meeting 124; reapproved by unanimous consent -------------------------------------------------------------------------- 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) --------------------------------------------------------------------------