########################################################################## # # # X3J3/S20.122 # # # # 29 September 1992 # # # ########################################################################## Number Title 000000 Minor edits and corrections to ISO/IEC 1539:1991 (E) 000001 Equivalence of Expression Evaluations 000002 Default Main Program Name 000003 Preconnected Units and UNIT=* 000004 Blanks in Format Specifications in Free Form Source 000005 Namelist Output of Zero Length Character Strings 000006 Procedure Specifications in a Scoping Unit 000007 Duplicate module procedures in interface blocks 000008 Module Procedure Name in Multiple Interface Blocks 000009 Generic Interfaces with the Same Name in a Program 000010 Generic Interfaces with the Same Name in a Scoping Unit 000011 Multiple Accessible Defined Assignment Interfaces 000012 Type of a Named Constant 000013 Implicit Environment of an Interface Block 000014 Interface for a Character Function with a Variable Length Result 000015 Error in Fourth Constraint for R429 000016 Character Length Specification 000017 000018 Valid Characters for Indicating Fixed Form Statement Continuation 000019 Correctness of Last Example in Section 4.5 000020 References to the Same Derived Type by Different Names 000021 References to Different Derived Types with the Same Name 000022 Use of Derived Type Name in Host Scoping Unit 000023 Type of a Named Constant in an Internal Procedure 000024 IMPLICIT NONE and the Type of an Internal Procedure Result 000025 Resolution of Internal Procedure References 000026 Bounds of Array Expressions 000027 Requirements for Pointers and Target Association 000028 Precedence of Use or Host Association 000029 Class of a Defined Operator 000030 Length of Character Literals in Array Constructors 000031 Scope and Type of an implied-DO Variable 000032 Implicit Declaration of a Derived Type 000033 Interface Blocks with the Same Name in a Program - I 000034 Interface Blocks with the Same Name in a Program - II 000035 Interface Blocks with the Same Name in a Program - III 000036 Pointer to an Assumed-size Array 000037 Use of Array Sections in Pointer Assignment Statements 000038 Same Interface Body in Multiple Generic Interface Blocks 000039 Association of a Pointer Actual Argument with a Dummy Argument 000040 Allocation of Arrays of Pointers 000041 Procedure with Target Dummy Argument Requires Explicit Interface 000042 KIND parameter value 000043 List-directed character input 000044 END Statement and Fixed Form Source 000045 Array Intrinsics with Arrays of Derived-type Arguments 000046 RESULT clause for RECURSIVE functions 000047 Automatic data object in initialization expressions 000048 Pointer-valued statement functions 000049 Characteristics of Function Results 000050 Repeat counts on edit descriptors 000051 On Unambiguous generic procedure references 000052 Expressions in Statement Function Definitions 000053 Optional Intrinsic Function Arguments 000054 Resolving Generic Procedure References 000055 Characteristics of character function results 000056 TRANSFER intrinsic function description 000057 Prohibition against multiple explicit specific interfaces 000058 Ambiguous use of "keyword" 000059 SEQUENCE derived type and component bounds 000060 Statement function argument references 000061 G edit descriptor with "d" = 0 000062 Statement function constraints 000063 Interfaces and dummy procedure arguments 000064 SPACING result for 0.0 000065 Block and Nonblock DO Construct 000066 Declaration of FUNCTION type 000067 Output of negative signed zero 000068 Pointer association status INTRODUCTION This document is an internal working document of X3J3, the Fortran Technical Committee of the American National Standards Association, and contains the committee's responses to the defect reports received against ISO/IEC 1539:1991 (E). The status of each item in this document is tracked with the STATUS field, the six values of which are: 1. X3J3 consideration in progress Submitted via the hardcopy route or via the RFI or RFC email route and being processed by X3J3, but as yet no response has been adopted by an X3J3 formal vote. 2. X3J3 draft response A response (ANSWER field) has been approved by a formal X3J3 vote but not yet approved by subsequent letter ballot. 3. X3J3 approved; ready for WG5 Approved by an X3J3 letter ballot. This vote will be taken only on items having a STATUS of "X3J3 draft response". 4. WG5 approved; ready for SC22 Approved by WG5 for further processing within ISO as a corrigendum item. WG5 will advise X3J3 when an item reaches this status. 5. Returned by WG5 for X3J3 reconsideration Returned to X3J3 after the item had been forwarded to WG5 but failed to gain WG5 approval. This status is equivalent to "X3J3 consideration in progress". 6. Published Published as an item in an approved corrigenda report, or incorporated into the next draft revision of the standard. In either case the item must have previously attained the status of "WG5 approved; ready for SC22". Each entry is categorized by its defect type of which there are three kinds (these definitions are taken from the X3/SD-2 of February 1992): 1. Erratum The standard may be modified with corrigenda to: a) Correct a typographical error. b) Insert a missing word, sentence, paragraph, figure, example, table, or clause. c) Delete a extraneous word, sentence, paragraph, figure, example, table, or clause. Any such modification of the standard shall not introduce technical changes or changes in what it means to conform to the standard. 2. Amendment Any modification of the standard that introduces technical changes or changes in what it means to conform to the standard shall be treated as an amendment to the standard. 3. Interpretation An interpretation is a clarifying commentary on the standard that does not introduce either a technical change or a change in what it means to conform to the standard. The first entry, which has the number 000000, contains details of minor edits and corrections to the standard. It is updated as required and the updates are tracked in the HISTORY section. ========================================================================== NUMBER: 000000 TITLE: Minor edits and corrections to ISO/IEC 1539:1991 (E) KEYWORDS: edits, typos, typographical errors DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: None. ANSWER: None. REFERENCES: ISO/IEC 1539:1991 (E) EDIT(S): 1. xvi/1-2 Delete the sentence "The section concludes ... names." 2. 15/25 Change "of" to "or". 3. 177/29 Add new sentence "When a statement function is invoked, an instance of that statement function is created." 4. 203/23 Change "1,sh" to "sh,1". 5. 220/25 Change",[" to "[" (i.e. delete comma). 6. 255/27 Change "2.4.7" to "2.4.5". 7. 255/38 Change "2.4.4" to "2.4.3.1.2". 8. 256/23 Change "2," to "2)". 9. 257/8 Change "2.4.7" to " 2.4.5". 10. 258/19 Change "2.4.4" to "2.4.3.1.2". 11. 258/22 Change "2," to "2)". 12. 258/25 Change "4," to "4)". 13. 258/34 Change "2.4.4" to "2.4.3.1.2". 14. 259/19 Change "3," to "3)". 15. 259/31 Change "2.4.7" to "2.4.5". 16. 260/12 Change "2.4.7" to "2.4.5". 17. 260/14 Change "2.4.7" to "2.4.5". 18. 260/35 Change "2.4.3.2" to "2.4.3.1". 19. 261/9 Change "specified in a" to "specified in a TARGET statement or". 20. 261/30 Change "2.4.5" to "2.4.3.1.1". SUBMITTED BY: WG5 (Victoria, BC) items 1 through 20. HISTORY: Items 1 through 20 approved as X3J3/92-152A at meeting 122 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000001 TITLE: Equivalence of Expression Evaluations KEYWORDS: arithmetic expressions, mathematical equivalence, numeric operations DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: In the following code fragments must the values of D be the same for all legal values of A, B, and C? TEMP=A+B D=C+TEMP and D=C+(A+B) ANSWER: No. Discussion: Section 7.1.7.3 "Evaluation of numeric operations", specifies that processors may evaluate any mathematically equivalent expression and notes, for example, that X+Y can be evaluated as Y+X. Thus, the statements in the question could legitimately be evaluated as: TEMP=A+B D=C+TEMP and D=C+(B+A) Consequently, there is no requirement that the computational result be the same. REFERENCE: ISO/IEC 1539:1991 (E) section 7.1.7.3 EDIT(S): None. SUBMITTED BY: J.C.Adams 119-JCA-2 (119.002) HISTORY: 119-RL-1 (119.012) 92-044 (S20.120A) 92-104 (Interpretation) Approved as 92-147 at meeting 122 by a vote of 21-1 -------------------------------------------------------------------------- NUMBER: 000002 TITLE: Default Main Program Name KEYWORDS: main program, default name DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Some implementations of FORTRAN 77 supply a default PROGRAM statement and program name when it is omitted from the main program. If the default program name conflicts with a global name in the program is the processor standard conforming or not? For example: COMMON /MAIN/ A(1000) READ *,N CALL SUB(N) END SUBROUTINE SUB(N) COMMON /MAIN/ A(1000) DO 100 I=1,N A(I)=0.0 100 CONTINUE END If a processor supplies a PROGRAM statement with a default name MAIN, this will conflict with the common block name MAIN. Is such a processor standard conforming? If the processor supplied a name which could never conflict with a FORTRAN 77 name, would it be standard conforming? Would the processor in the example above be standard conforming if it used M_A_I_N, for example, instead of MAIN? ANSWER: This situation is covered by the third paragraph of of section 1.4 of ANSI X3.9-1978 Programming Language FORTRAN. Specifically, lines 25-27 state: A processor conforms to this standard if it executes standard-conforming programs in a manner that fulfills the interpretations prescribed herein. If, as in the example provided, the processor supplies a PROGRAM statement for a main program with a symbolic name which conflicts with another global name in the program, such that the program fails to execute then the processor does not conform to the standard. The processor may supply a default name which does not conflict with another global name and be standard conforming. Note that in Fortran 90 this situation is explicitly described in section C.11.1. REFERENCES: ISO/IEC 1539:1991 (E) section C.11.1 ANSI X3.9-1978 section 1.4 (page 1-2, lines 25-27) EDIT(S): None. SUBMITTED BY: A. D. Tait, 117-ADT-5 (117.035), 118-ADT-3 (118.045) HISTORY: 119-ADT-1 (119.012), 119-RL-2 (119.048) X3J3 draft response at meeting 120 ----------------------------------------------------------------------- NUMBER: 000003 TITLE: Preconnected Units and UNIT=* KEYWORDS: preconnected units, identifying a unit, UNIT=* DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Is a processor which associates preconnected units with the files identified by the * in READ and WRITE statements standard conforming? ANSWER: Yes. Discussion: This situation is covered by section 12.9.2 of ANSI X3.9- 1978 Programming Language FORTRAN. This section states that the asterisk identifies a particular processor-determined unit which is the same for a PRINT statement and a WRITE statement which contains an asterisk. The processor-determined unit is different for a READ statement which contains an asterisk. Note that in Fortran 90 this situation is explicitly described in section 9.3. REFERENCES: ISO/IEC 1539:1991 (E) sections 9.3 & 9.4.4.2 ANSI X3.9-1978 section 12.9.2 EDIT(S): None. SUBMITTED BY: A. D. Tait, 118-ADT-2 (118.024) HISTORY: Approved as 119-ADT-2 (119.013) ----------------------------------------------------------------------- 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 name, 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: -- letters in edit descriptors are not in the category "keywords" and need not be delimited by blanks. -- blanks are allowed in edit descriptors. REFERENCES: ISO/IEC 1539:1991 (E) sections 3.3.1, 10.1.1 EDIT(S): Note that the edits defined in NUMBER 000058 must be applied before those lised below. 1. Section 3.2 page 19 last sentence [19:35-36] insert ", edit descriptors" following "... , labels". 2. 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]...'." 3. Section 3.3.1 p22 2nd pp [22:6] change "... character context." to "... character context or in a format specification." SUBMITTED BY: J.T. Martin 119-JTM-2 (119.015) HISTORY: X3J3/92-145 Draft Interpretation by CIO, withdrawn X3J3/92-075 X3J3/92-044 S20.120, number 4 119-RPK-1 119-JTM-2 Approved as X3J3/92-176 at meeting 122 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000005 TITLE: Namelist Output of Zero Length Character Strings KEYWORDS:namelist output, zero length, character string DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Given the program: PROGRAM P CHARACTER*0 CH NAMELIST/OUT/CH OPEN(UNIT=8,DELIM='NONE') WRITE(UNIT=8,NML=OUT) END The namelist output record would be: &OUT CH= / Does not this conflict with the statement in section 10.9.2.2 that: A null value is not produced by namelist formatting. ANSWER: No. Discussion: Although the output produced by this program appears to contain a null value (to namelist input), actually a zero-length character string was written by the namelist output statement. Note that this is different from a null value (section 10.9.1.4) which has no meaning on output. The statement: A null value is not produced by namelist formatting. indicates that since all namelist group objects have a value, that value (in this case a zero-length string) is output. REFERENCES: ISO/IEC 1539:1991 (E) sections 10.9.1.4, & 10.9.2.2, EDIT(S): None. SUBMITTED BY: J. T. Martin, 119-JTM-3 (119.016) HISTORY: 119-RPK-2 (119.064), & 119-JTM-6 (119.041) ----------------------------------------------------------------------- NUMBER: 000006 TITLE: Procedure Specifications in a Scoping Unit KEYWORDS: procedure specification, scoping unit, interface body DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Which of the following procedure related specifications may jointly occur within a scoping unit? a. An interface body for the procedure and the appearance of the procedure name in a type statement b. An interface body for the procedure and the appearance of the procedure name in an EXTERNAL statement c. A module procedure definition and the appearance of the procedure name in a type statement d. A module procedure definition and an interface body for the procedure ANSWER: None.of the above. Discussion: Section 5.1 states the generally applicable constraint: An entity must not be given explicitly any attribute more than once in a scoping unit. An interface body provides an explicit interface to the procedure. This interface includes the characteristics of the procedure: these characteristics include, for a function, the type of the value returned. Thus, the interface body is an explicit declaration of the function result type, and this must not also be declared in a type statement (a). Similarly, a module procedure definition includes a declaration of its interface, so its presence precludes the presence of either a type statement declaring function result (b) or an interface body declaring its characteristics (c). The case of the module procedure definition and interface body is also covered by the statement in 12.3.2.1 that A procedure must not have more than one explicit specific interface in a given scoping unit. and by the fact that the statement (also in 12.3.2.1): An interface body in an interface block specifies an explicit interface for an existing external procedure or a dummy procedure, does not include module procedures. The latter statement in conjunction with the sentence which follows it also shows that the interface body declares the same attributes as the EXTERNAL statement, so this combination is similarly prohibited (d). This last case may be less than obvious. This deficiency is remedied by an edit to provide an explicit prohibition to cover this case. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1, & 12.3.2.1 EDIT(S): At the end of the fourth paragraph following R1207 in 12.3.2.2, add A name that appears in an EXTERNAL statement must not also appear as a specific procedure name in an interface block in the scoping unit. SUBMITTED BY: S. M. Lammers, 119-SML-1 (119.019) items 1 through 4 HISTORY: Approved as X3J3/92-170 at meeting 122 by unanimous consent -------------------------------------------------------------------------- NUMBER: 000007 TITLE: Duplicate module procedures in interface blocks KEYWORDS: module procedure name, interface block, generic DEFECT TYPE: Amendment STATUS: X3J3 draft response QUESTION: May a module procedure name be referenced on more than one MODULE PROCEDURE statement for a given generic name in a scoping unit, either in a single interface block or in multiple interface blocks specifying that generic name? ANSWER: No. Discussion: The standard routinely disallows such redundant specifications within a scoping unit. The prohibition for this case was inadvertently overlooked. This deficiency is remedied by the supplied edit. Example: INTERFACE INT_1 MODULE PROCEDURE FOO, FOO ! second FOO is illegal MODULE PROCEDURE FOO1 MODULE PROCEDURE FOO1 ! FOO1 is illegal here END INTERFACE INT_1 INTERFACE INT_2 MODULE PROCEDURE FOO2A, FOO2B END INTERFACE INT_2 INTERFACE INT_2 MODULE PROCEDURE FOO2B, FOO2C !FOO2B is illegal here END INTERFACE INT_2 Note, however, that if the two interface blocks for INT_2 were placed in separate modules, the second appearance of FOO2B would have been permitted, as would a scoping unit which used both modules. For example: MODULE MOD1 USE SOME_OTHER_MODULE ! the source of FOO2B INTERFACE INT_2 MODULE PROCEDURE FOO2A, FOO2B END INTERFACE INT_2 ... END MODULE MOD1 MODULE MOD2 USE SOME_OTHER_MODULE ! the source of FOO2B INTERFACE INT_2 MODULE PROCEDURE FOO2B, FOO2C !FOO2B is legal here END INTERFACE INT_2 ... END MODULE MOD2 The following USE statements would be allowed: USE MOD1 USE MOD2 ! no problem using both modules here EDIT(S): The following additional constraint should be added to section 12.3.2.1: Constraint: A in a must not be one which previously had been established to be associated with the of the in which it appears, either by a previous appearance in an or by use or host association. REFERENCES: ISO/IEC 1539:1991(E) Section 12.3.2.1 SUBMITTED BY: S.M.LAmmars, 119-SML-1 (119.019) HISTORY: Original interpretation was 120-MBSH-4A (120.096A) Modified based on X3J3/92-039 arguments. Adopted because this interpretation is more consistent with requirements concerning duplication of other specification statements in a given scoping unit. Interpretation modification presented in X3J3/92-095 Commented on by N786A from WG5 Victoria meeting in item marked 1167/36+. Approved as X3J3/92-155A at meeting 122 by unanimous consent. -------------------------------------------------------------------------- NUMBER: 000008 TITLE: Module Procedure Name in Multiple Interface Blocks KEYWORDS: module procedure name, interface block DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: May a module procedure name be referred to on more than one MODULE PROCEDURE statement in multiple interface blocks specifying the same generic name? ANSWER: Yes. Discussion: There is no restriction that forbids the situation in this question and therefore it is legal. Example: INTERFACE INT_1 MODULE PROCEDURE FOO,FOO ! FOO is illegal MODULE PROCEDURE FOO1 MODULE PROCEDURE FOO1 ! FOO1 is illegal MODULE PROCEDURE FOO2 END INTERFACE INT_1 INTERFACE INT_1 MODULE PROCEDURE FOO2 ! legal END INTERFACE INT_1 REFERENCES: 120-MBSH-4A (120.096A) EDIT(S): None. SUBMITTED BY: S. M. Lammers, 119-SML-1 (119.019) item 5, question 4 HISTORY: Interpretation questioned in X3J3/92-039 Resolved by X3J3/92-155A (approved by unanimous consent as the response to NUMBER 000007) ----------------------------------------------------------------------- NUMBER: 000009 TITLE: Generic Interfaces with the Same Name in a Program KEYWORDS: generic, interface, name DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: May two generic interfaces of the same name be accessed by use association in the same scoping unit? Discussion: Can the following program fragment be part of a standard conforming program? MODULE MOD1 INTERFACE INT1 ... END INTERFACE END MODULE MOD1 MODULE MOD2 INTERFACE INT1 ... END INTERFACE ... END MODULE MOD2 PROGRAM EXAMPLE_1 USE MOD1 USE MOD2 ANSWER: Yes. As can be seen in section 11.3.2: If two or more generic interfaces that are accessible in a scoping unit ... they are interpreted as a single generic interface. REFERENCES: ISO/IEC 1539:1991 (E) section 11.3.2 (paragraph 5 after last constraint). EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-4 (120.029), question 1 HISTORY: Proposed as 120-MBSH-1A (120.084A) at meeting 120 Questioned in X3J3/92-040 (121-JKR-8) Approved as X3J3/92-099 ----------------------------------------------------------------------- NUMBER: 000010 TITLE: Generic Interfaces with the Same Name in a Scoping Unit KEYWORDS: generic, interface, name, scoping unit DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Are two generic interfaces with the same name allowed in the same scoping unit? Discussion: For example can this program fragment be part of a standard conforming program? PROGRAM EXAMPLE_1 INTERFACE INT1 ... END INTERFACE ... INTERFACE INT1 ... END INTERFACE ANSWER: Yes. As can be seen in section 11.3.2: If two or more generic interfaces that are accessible in a scoping unit ... they are interpreted as a single generic interface. REFERENCES: 120-MBSH-1A (120.084A) EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-4 (120.029), question 2 HISTORY: Proposed as 120-MBSH-1A (120.084A) at meeting 120 Questioned in X3J3/92-040 (121-JKR-8) Approved as X3J3/92-100 ---------------------------------------------------------------------- NUMBER: 000011 TITLE: Multiple Accessible Defined Assignment Interfaces KEYWORDS: interfaces, defined assignment DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Did the standard intend to prohibit multiple accessible defined assignment interfaces? ANSWER: No. Discussion: The standard specifically includes "generic interfaces" of "the same name, the same operator, or are both assignments" in the rule of what will be interpreted as having a "single generic interface". The text cited on local entities was specifically discussing "names" and hence "generic names" were singled out. 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 HISTORY: 120-MBSH-1A (120.084A) ----------------------------------------------------------------------- NUMBER: 000012 TITLE: Type of a Named Constant KEYWORDS: named constant, parameter statement DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Is the following code fragment valid Fortran 90? PARAMETER (A=1) IMPLICIT INTEGER (A) ANSWER: No. Discussion: In any scoping unit there is only one (possibly null) implicit typing map (5.3). Thus, in the statement (5.2.10), The named constant must have its type, shape, and any type parameters specified either by a previous occurrence in a type declaration statement in the same scoping unit, or 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. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.2.10 & 5.3 EDIT(S): None. SUBMITTED BY: J. T. Martin, 120-JTM-9 (120.046), question 3 HISTORY: 120-LJM-5 (120-098) Response in X3J3/92-172, must be identical to response to NUMBER 000023 ----------------------------------------------------------------------- NUMBER: 000013 TITLE: Implicit Environment of an Interface Block KEYWORDS: implicit environment, interface block DEFECT TYPE: Amendment STATUS: X3J3 draft response QUESTION: Is the implicit environment of the host inherited by an interface block? ANSWER: No. Discussion: Unlike other scoping units that are contained within a host scoping unit, an interface body does not access entities from its host by host association. This was intended to allow the initial statements of an external procedure to be used without modification in an interface body describing that procedure. The possibility of there being different implicit mappings was inadvertently overlooked. If not corrected, this would mean that: FUNCTION F(X,I) F = X**I/I END FUNCTION F would be properly described by: INTERFACE FUNCTION F(X,I) END FUNCTION F END INTERFACE if the interface block is contained in a host with default implicit mapping, but not in one containing the statement: IMPLICIT INTEGER (A-Z) The default implicit mapping in an interface body is made consistent with that in an external procedure by the supplied edit. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.2 & 5.3 EDIT(S): 1. In Section 5.3 in the second paragraph after the constraints, in the phrase: "the default is the mapping ...", after "default" add "for a program unit or an interface body is default integer if the letter is I,J, ... , or N and default real otherwise, and the default for an internal or module procedure". Delete "A program ... O-Z)" 2. In the example in section 5.3 for FUNCTION FUN in the interface block the comment should be changed from: ! All data entities must ! be declared explicitly to ! Not all entities need be ! declared explicitly 3. In the first example in section 5.3, change "INTEGER FUN, I" to be "INTEGER FUN". SUBMITTED BY: L.R.Rolison 120-LRR-3 (120.028) HISTORY: Draft response in 92-102A, questioned in N786A of the Victoria WG5 meeting. Revised edit approved as 92-154A at meeting 122 by a vote of 21-1. -------------------------------------------------------------------------- NUMBER: 000014 TITLE: Interface for a Character Function with a Variable Length Result KEYWORDS: character function, variable length, interface DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Given a definition of an external function such as the following where the function result is variable length, must the characteristics of the function be described by an interface block accessible to the calling scoping unit? FUNCTION F(I) INTEGER I,N CHARACTER*(N) F COMMON /B/ N ... END ANSWER: Yes. Discussion: Section 12.3.1.1 states: A procedure must have an explicit interface if ... (2) The procedure has ... (d) A result whose length type parameter value is neither assumed nor constant." That provision applies to this function. Section 12.3.1 indicates that an external procedure has an explicit interface only if an interface block is provided. REFERENCES: ISO/IEC 1539:1991 (E) section 12.3.1 & 12.3.1.1 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 119-LRR-1, part II HISTORY: 119-KWH-3A (119-70A) ----------------------------------------------------------------------- NUMBER: 000015 TITLE: Error in Fourth Constraint for R429 KEYWORDS: constraints, R429, DEFECT TYPE: Amendment STATUS: X3J3 draft response QUESTION: Should the fourth constraint for R429 also apply to a in the ? ANSWER: Yes. Discussion: A nonconstant specification expression specifies an automatic character object that may be declared only in a procedure or procedure interface. It was never the intention to permit the specification of automatic objects in type definitions. The fifth constraint for R429 prohibits the only other automatic object, an automatic array. By extrapolation, it could be assumed that the length specified in a character would be similarly restricted. REFERENCES: ISO/IEC 1539:1991 (E) sections 4.4.1, 5.1, 5.1.1.5, & 7.1.6.2 EDIT(S): The fourth constraint after R429 should be: The character length specified by the in a or the in a (5.1, 5.1.1.5) must be a constant specification expression (7.1.6.2) SUBMITTED BY: J. T. Martin, 119-JTM-7 (119.042) part 1 HISTORY: 119-JTM-11 (119.054) ----------------------------------------------------------------------- NUMBER: 000016 TITLE: Character Length Specification KEYWORDS: character length specification, , R508 DEFECT TYPE: Amendment STATUS: X3J3 draft response QUESTION: is there a similar interaction between a specified in both a and a as there is between a specified in both an and a ? ANSWER: Yes. Discussion: It was intended that character declarations in type definitions be symmetrical with character object declarations. REFERENCES: ISO/IEC 1539:1991 (E) sections 4.4.1, 5.1, & 5.1.1.5 EDIT(S): The text following the constraints for R508 should be: The in a CHARACTER and the * in an or in a of a type definition specify character length. The * in an or specifies an individual length and overrides the length specified in the , if any. If a * is not specified in an or , the or specified in the is the character length. If the length is not specified in a or a * , the length is 1. SUBMITTED BY: J. T. Martin, 119-JTM-7 (119.042) part 2 HISTORY: 119-JTM-12A (119.055A) ----------------------------------------------------------------------- NUMBER: 000017 TITLE: KEYWORDS: DEFECT TYPE: Undecided STATUS: X3J3 consideration in progress QUESTION: ? ANSWER: Multiple renames of the same do not constitute separate entities. Subsequent appearances of the refer to the single entity. For example: MODULE UTIL PROCEDURE P PUBLIC P END MODULE UTIL MODULE MID1 USE UTIL, Q=>P !Q is merely a renaming of P PUBLIC Q END MODULE MID1 MODULE MID2 USE UTIL, Q=>P !another renaming of the same entity P PUBLIC Q END MODULE MID2 SUBROUTINE ENDUSER USE MID1 USE MID2 CALL Q(...) !This is legal and refers to P END SUBROUTINE ENDUSER The portion of the standard in 11.3.2: Two or more accessible entities, other than generic interfaces, may have the same name only if no entity is referenced by this name in the scoping unit Use "referenced" in the ordinary English sense rather than its technical sense. That is, two or more accessible entities with the same name must not appear in the same scoping unit. So: USE MID, AA=>BB USE MID, AA=>CC is prohibited by the standard REFERENCES: ISO/IEC 1539:1991 (E) section 11.3.2 EDIT(S): None. SUBMITTED BY: E. A. Johnson, 119-EAJ-1 (119.057) HISTORY: 120-LF-1 (120.089) ----------------------------------------------------------------------- NUMBER: 000018 TITLE: Valid Characters for Indicating Fixed Form Statement Continuation KEYWORDS: fixed form source, statement continuation, character set DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Line 3 of the first paragraph of 3.3.2.3 states: If character position 6 contains any character other than a blank or zero, character position 7-72 of this line constitute a continuation of the preceding noncomment line. Can the character in character position 6 be a character outside the Fortran character set (for example, newline)? ANSWER: No. Section 3.1.5 specifies where additional characters not in the Fortran character set may be used. REFERENCES: ISO/IEC 1539:1991 (E) sections 3.1 & 3.3.2.3 EDIT(S): None. SUBMITTED BY: J. C. Adams, 120-JCA-13 (120.013) HISTORY: Originally proposed as 120-RL-1 (120.058) Approved as X3J3/92-105 at meeting 121 by a vote of 20-0 ----------------------------------------------------------------------- NUMBER: 000019 TITLE: Correctness of Last Example in Section 4.5 KEYWORDS: DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Is the order of the coordinates correct in the last example of 4.5, considering the type definition of LINE in 4.4.1? ANSWER: Yes. Discussion: If the line is drawn between points X and Y where the coordinates of X are X1 and X2 and the coordinates of Y are Y1 and Y2. Admittedly, this is not the traditional naming scheme for the coordinates of two points that determine a line. Traditionally, a line would be drawn between points 1 and 2 where each point had an X and Y coordinate, but it is merely a matter of naming. Customary expectations would have been better satisfied if the first comment in the type definition of line in 4.4.1 were !X1, X2, Y1, Y2. In future revisions of the standard more care will be taken to create examples based on traditional naming schemes. REFERENCES: ISO/IEC 1539:1991 (E) sections 4.4.1 & 4.5 EDIT(S): None. SUBMITTED BY: J. C. Adams, 120-JCA-14 (120.014) HISTORY: 120-JTM-10 (120.057) ----------------------------------------------------------------------- NUMBER: 000020 TITLE: References to the Same Derived Type by Different Names KEYWORDS: derived types, same type, derived type definition DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: How does changing the name by which a derived type is referenced affect its use? For example, is the code below standard conforming and, if so, which specific procedure is invoked by the reference to GEN? MODULE MOD TYPE T1 SEQUENCE INTEGER I,J END TYPE T1 END MODULE MOD USE MOD, T2=>T1 TYPE (T2) X INTERFACE GEN SUBROUTINE SPEC1(A1) TYPE T1 SEQUENCE INTEGER I,J END TYPE T1 TYPE (T1) A1 END SUBROUTINE SPEC1 SUBROUTINE SPEC2(A2) TYPE T2 SEQUENCE INTEGER I,J END TYPE T2 TYPE (T2) A2 END SUBROUTINE SPEC2 END INTERFACE GEN INTERFACE SUBROUTINE SPEC3(A3) USE MOD TYPE (T1) A3 END SUBROUTINE SPEC3 END INTERFACE ... CALL SPEC3(X) CALL GEN(X) END ANSWER: Yes, the code is standard conforming. The reference to GEN should invoke the specific procedure SPEC1. Discussion: The rules governing these questions are stated in 4.4.2. Two alternatives are provide for entities to have the same type. The first alternative applies to the reference to SPEC3: Two data entities have the same type if they are declared with reference to the same derived-type definition. In this case, both the actual argument X and the dummy argument A3 are declared with reference to the type definition T1 in MOD. The second alternative applies to the analysis of the procedures in generic interface GEN: Data entities in different scoping units also have the same type if they are declared with reference to different derived-type definitions that have the same name, have the SEQUENCE property, and have structure components that do not have PRIVATE accessibility and agree in order, name, and attributes. The type definition in SPEC1 has the agreement with the type definition in MOD, so X and A1 have the same type. The definition in SPEC2 has a different name, so X and A2 have different types. Thus the reference to GEN invokes SPEC1. Note the fact that type T1 in MOD was accessible using a different name in the main program was irrelevant in both these analyses. REFERENCES: ISO/IEC 1539:1991 (E) section 4.4.2 EDIT(S): None. SUBMITTED BY: J. C. Adams, 120-JCA-15 (120.015), 120-JLS-5 (120.023) HISTORY: 120-KWH-1 (120.078) ----------------------------------------------------------------------- NUMBER: 000021 TITLE: References to Different Derived Types with the Same Name KEYWORDS: derived type definition DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: In the following example, to which type T1 does the FUNCTION statement refer? SUBROUTINE FRED TYPE T1 REAL :: X,Y END TYPE ... CONTAINS TYPE (T1) FUNCTION WILMA() TYPE T1 INTEGER I,J END TYPE ... END FUNCTION WILMA END SUBROUTINE FRED ANSWER: It is the type T1 of WILMA. Discussion: Section 12.1.2.2.1 states: A name that appears in the scoping unit as (1) a in a ... is the name of a local entity and any entity of the host that has this as its nongeneric name is inaccessible. Therefore, the type T1 defined in FRED is not accessible in WILMA and cannot be the type referenced in the function statement. Note that it is impossible to reference WILMA because its type T1 is not known outside WILMA. Were the SEQUENCE attribute added to the definition of T1 and the component types of the two T1 declarations the same so that the two T1 declarations met the requirements of being the "same derived types" (4.4.2), then a reference to WILMA would be possible. REFERENCES: ISO/IEC 1539:1991 (E) sections 4.4.2, 5.3, 12.1.2.2.1, & 12.5.2.2 EDIT(S): None. SUBMITTED BY: J. L. Steidel, 120-JLS-1 (120.019) HISTORY: Originally answered in 120-KWH-2A (120.083A) Modification requested by X3J3/92-037 (121-JKR-5) Discussed in X3J3/92-049 (121-ADT-9) p7 & X3J3/92-050 (121-ADT-10) p4 Approved as X3J3/92-080 at meeting 121 by a vote of 20-0 ----------------------------------------------------------------------- NUMBER: 000022 TITLE: Use of Derived Type Name in Host Scoping Unit KEYWORDS: derived type, , host scoping unit, internal proc. DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following code fragment: SUBROUTINE HOST TYPE T1 INTEGER I,J END TYPE ... CONTAINS FUNCTION CONTAINED () IMPLICIT TYPE (T1) C TYPE T1 INTEGER I,J END TYPE END FUNCTION CONTAINED END SUBROUTINE HOST Is it standard conforming to redefine T1 following the IMPLICIT statement that maps to T1? Does the fact that the function name begins with the letter being mapped have any significance in that determination? If an argument named C were added to the dummy argument list of CONTAINED, would that have any effect? ANSWER: The redefinition is permitted. The fact that the type of CONTAINED is implicitly mapped has no significance. The inclusion of an argument named C would have no significance in the redefinition of T1, but would render the program unit nonstandard conforming for other reasons. Discussion: Section 12.1.2.2.1 states: A name that appears in the scoping unit as (1) a in a ... is the name of a local entity and any entity of the host that has this as its nongeneric name is inaccessible. Therefore the type T1 of HOST is inaccessible in the scoping unit of CONTAINED. The function statement is part of the scoping unit of CONTAINED since R1215 says that a function statement is part of its subprogram and it is not excluded in item (3) of the definition of a scoping unit in section 2.2. It follows that the type must be the local type. Note that although this is legal, it is not very useful. Since the type of CONTAINED is local to CONTAINED, CONTAINED cannot be referenced. To be useful, when the type of a procedure is of nonsequence derived type, the derived-type definition must be accessible in the scoping unit of the procedure by either host association or use association. If a dummy argument is of nonsequence derived type, this principle is mandated in 5.1.1.7: A declaration for a nonsequence type derived-type dummy argument must specify a derived type that is accessed by use association or host association because the same definition must be used to declare both the actual and dummy arguments to ensure that both are of the same derived type. This restriction does not apply to arguments of sequence type (4.4.2)... If the SEQUENCE attribute were present, and the types were the same as mandated by 4.4.2, then the program would be legal and the entire function with the dummy argument could be referenced in the host. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.2, 4.4.2, 12.1.2.2.1, & 12.5.2.2 EDIT(S): None. SUBMITTED BY: J. L. Steidel, 120-JLS-2 (120.020) cases 1 and 2 HISTORY: Proposed as 120-RPK-1A (120.092A) Questioned by X3J3/92-038 (121-JKR-6) Approved as X3J3/92-097 at meeting 121 by a vote of 20-0 ----------------------------------------------------------------------- NUMBER: 000023 TITLE: Type of a Named Constant in an Internal Procedure KEYWORDS: named constant, internal procedure, parameter statement, host DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Given that an implicit mapping is established for a letter in a host scoping unit. An internal procedure of that host scoping unit contains a PARAMETER statement which defines a named constant whose name begins with the letter in question. This is followed by an IMPLICIT statement which defines a different mapping for this letter. Is this legal? ANSWER: No. Discussion: 5.3 indicates that: In each scoping unit, there is a mapping, ... between each of the letters ... and a type... Hence within the internal procedure, the implicit mapping for X is to the type CHARACTER and the PARAMETER statement is illegal. REFERENCES: ISO/IEC 1539:1991 (E) section 5.3 EDIT(S): None. SUBMITTED BY: J. L. Steidel, 120-JLS-2 (120.020) case 3 HISTORY: 120-LJM-5 (120-093) Response in X3J3/92-172, must be identical to response to NUMBER 000012 ----------------------------------------------------------------------- NUMBER: 000024 TITLE: IMPLICIT NONE and the Type of an Internal Procedure Result KEYWORDS: IMPLICIT NONE, internal procedure, function result type DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: An internal procedure contains an IMPLICIT NONE statement and does not contain a type specification for the function result. Is this legal? ANSWER: No. Discussion: 12.5.2.2 states if the type of the function result is not explicitly specified: ... it is determined by the implicit typing rules in force within the function subprogram. As the null mapping has been specified for all letters within the internal function, the type of the result must be explicitly specified within the function. REFERENCES: ISO/IEC 1539:1991 (E) section 12.5.2.2 EDIT(S): None. SUBMITTED BY: J. L. Steidel, 120-JLS-2 (120.020) case 4 HISTORY: 120-RPK-3A (120-094A) ----------------------------------------------------------------------- NUMBER: 000025 TITLE: Resolution of Internal Procedure References KEYWORDS: host, internal procedure, IMPLICIT NONE, procedure references DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: A host scoping unit contains two internal functions, F1 and F2. If F1 contains an IMPLICIT NONE and references F2, must F1 contain an explicit type declaration for F2? ANSWER: No. In fact if it did contain an explicit type specification for F2, F1 would be referencing an external function F2 and not the internal one contained in its host scoping unit. Discussion: 12.3.1 states: If a procedure is accessible in a scoping unit, its interface is either explicit or implicit in that scoping unit. The interface of an internal procedure ... is always explicit in such a scoping unit. Therefore, the interface of F2 is explicit in the host scoping unit. The function F2 is established to be specific in the host scoping unit by (2)(b) of 14.1.2.4 which states that a procedure name is specific: if that scoping unit contains a ... an internal procedure ... with that name; Furthermore, the function name F2 is established to be specific in the internal procedure F1 by (2)(f) of 14.1.2.4 which states that a name is specific: if that scoping unit contains no declarations of that name, that scoping unit is contained in the host scoping unit, and that name is established to be specific in the host scoping unit. As F2 is established to be specific within F1 by the above, 14.1.2.4.2 indicates that the F2 referenced by F1 is to the internal function F2 contained in the host scoping unit. Note that if F1 contains an explicit declaration for F2, by the rules of 14.1.2.4, F2 is not established to be either generic or specific in F1. Therefore, to resolve the procedure reference, the rules in 14.1.2.4.3 apply and the reference to F2 within F1 is to an external procedure with the name F2. REFERENCES: ISO/IEC 1539:1991 (E) section 12.3.1, 14.1.2.4, 14.1.2.4.2 & 14.1.2.4.3 EDIT(S): None. SUBMITTED BY: J. L. Steidel, 120-JLS-2 (120.020) case 5 HISTORY: Proposed meeting 120 120-RPK-4 (120-095) Questioned X3J3/92-050 (121-ADT-10) page 4 X3J3 draft response at meeting 121 ----------------------------------------------------------------------- NUMBER: 000026 TITLE: Bounds of Array Expressions KEYWORDS: lower bound, upper bound, array expression DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Is it the intent of the standard is to state that the lower bound of an array expression is always 1, and the upper bound is equal to the number of elements in a given dimension, for all dimensions. Thus, given: REAL,TARGET,DIMENSION(5:10) :: A REAL,DIMENSION(:),POINTER :: P P => A(5:10) PRINT *, LBOUND (P) the print statement results in the value 1 being written. Previous versions of the draft state lower bounds of array expressions were 1. Where are those words in the current draft? Reading chapter 7 indicates that an expression may be a simply a primary, and a primary may be an array variable. Question 1: Does this mean, given the above declarations that P => A PRINT *, LBOUND (P) would also result in the value 1 being written (since A is an array expression), or should this print the value 5? Question 2: Is the intent of the standard that given an array with a declared lower bound other than one, the following relational expressions are false? REAL,TARGET,DIMENSION(5:10) :: A REAL,DIMENSION(:),POINTER :: P1, P2 INTERFACE SUBROUTINE FRED (X, Y) REAL,INTENT (IN),DIMENSION(:) :: X, Y END SUBROUTINE END INTERFACE P1 => A P2 => A(:) PRINT *, LBOUND (A) .EQ. LBOUND (A(:)) PRINT *, LBOUND (P1).EQ. LBOUND (P2) CALL FRED (A, A(:)) END SUBROUTINE FRED (X, Y) REAL,INTENT(IN),DIMENSION(:) :: X, Y PRINT *, LBOUND (X) .EQ. LBOUND (Y) END SUBROUTINE Question 3: If the above three print statements result in the values .FALSE., in what cases does the appearance of an array name constitute an array (carrying with it its dimension attributes), and in what cases does it constitute an expression (implying the lower bound is one)? That is, in cases where bounds information may be transmitted (pointer assignment and actual argument association at subprogram calls), does the appearance of an array or pointer name *without* a subscript following cause the bounds of the array or pointer to be transmitted, and does the appearance of the same array or pointer name followed by a subscript triplet with no lower or upper bound or stride (i.e. (:,:)) constitute an expression with a lower bound of one transmitted? In summary: (a) What are the bounds of an array pointer which has been pointer assigned to an array section? (b) What are the bounds of an array pointer which has been pointer assigned to a whole array? (c) What are the bounds of an assumed shape array? (d) What are the bounds of a pointer dummy argument? ANSWER: The output of the three example programs would be: 1) 1 2) 5 3) .FALSE. .FALSE. .TRUE. (a) Each lower bound is 1, and each upper bound is the size of the corresponding dimension of the array section. (b) The declared bounds of the whole array. (c) Each lower bound is the declared lower bound of the assumed shape array, or, if omitted, 1, and each upper bound is the size of the corresponding dimension of the array section plus the lower bound minus one. (d) The bounds of the target associated with the pointer actual argument. Discussion: Cases (a) and (b) are determined from the statements (5.1.2.4.3), ...The lower bound of each dimension is the result of the LBOUND function (13.13.52) applied to the corresponding dimension of the target. The upper bound of each dimension is the result of the UBOUND function (13.13.111) applied to the corresponding dimension of the target. Case (d) is determined from these statements in conjunction with the statement, "If the actual argument is currently associated, the dummy argument becomes associated with the same target" (12.4.1.1). Case (c) is described in section 5.1.2.4.2. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1.2.4.2, 5.1.2.4.3, 12.4.1.1, 13.13.52, & 13.13.111 EDIT(S): None. SUBMITTED BY: J. L. Steidel, 120-JLS-3 (120.021) HISTORY: 120-LJM-4A (120.088A) ----------------------------------------------------------------------- NUMBER: 000027 TITLE: Requirements for Pointers and Target Association KEYWORDS: POINTER attribute, TARGET attribute, pointer association DEFECT TYPE: Interpretation STATUS: X3J3 draft response 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 .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: ASSOCIATED(PTR,TGT) returns false under any of the above conditions except, possibly, (f). 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. 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) 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 ----------------------------------------------------------------------- NUMBER: 000028 TITLE: Precedence of Use or Host Association KEYWORDS: use association, host association DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: is an implicitly typed entity with the same name as a host or use associated entity a reference to a local entity or the host or use associated entity? ANSWER: It is a reference to the host or use associated entity. 5.3, fourth paragraph (after IMPLICIT INTEGER (I-N), REAL (A-H,O-Z)) states that use or host association takes precedence over implicit typing. REFERENCES: ISO/IEC 1539:1991 (E) section 5.3 EDIT(S): None. SUBMITTED BY: J. L. Steidel, 120-JLS-6 (120.024)) HISTORY: 120-RL-3 (120.060) ----------------------------------------------------------------------- NUMBER: 000029 TITLE: Class of a Defined Operator KEYWORDS: defined operator, generic identifier, classes of local entities DEFECT TYPE: Erratum 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: "defined operator name" is not a Fortran 90 concept. We assume the question can be rewritten as: Is a defined operator a generic identifier? Thus is it illegal for a defined operator to be the same as another class 1 entity within the same scoping unit (As defined in 14.1.2)? Further we note that Section 14 uses the undefined term "generic operator" and we shall change the three occurrences to be "defined operator". Proceeding, given those corrections, we have: For the first part of the question: Is a defined operator a generic identifier? the answer is "YES". 12.3.2.1 p168 in the pp beginning "A procedure" states: The generic name, defined operator, or ... is a generic identifier. For the 2nd part of the question: Thus is it illegal for a defined operator to be the same as another class 1 entity within the same scoping unit (as defined in 14.1.2)? we will divide the entities in 14.1.2 class 1 into two categories and, at the same time, replace "generic identifiers" with "generic name, defined operator, and equals symbol" (from the definition of generic identifier, 12.3.2.1). The two categories of interest are then: named variables that are not statement entities, named constants, named constructs, statement functions, internal procedures, module procedures, dummy procedures, intrinsic procedures, generic names, equal symbol, derived types, and namelist group names and defined operators For the first category, "named variables that are ....", we note that defined operators, R704 and R724, are syntactically disjoint from names, R304, and equal symbols and thus cannot be the same as any entity in this category. For example, given the expression: (.SAM.SAM) ".SAM." is a defined unary operator and "SAM" is a name. That both share the letters "SAM" has no effect on their interpretations. The answer, then, for this category, is that it is not possible to construct a defined operator that is the same as a member of this category. For the second category, "defined operators", we note that 12.3.2.1.1 states: A given defined operator may, as with generic names, apply to more than one function, in which case it is generic in exact analogy to generic procedure names. Unfortunately, section 14 contains an error and is not consistent with section 12. 14.1.2 p241 in the pp beginning "Within a scoping unit, a name that" reads: 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). This text fails to consider defined operators; an edit is specified, below, to make defined operators an exact analogy to generic names as stated in 12.3.2.1.1. With this correction, the answer for this category is "NO". We also note the term "generic procedure names" in 12.3.2.1.1, above, is not consistent with the many references to "generic names" and have included edits for that correction. REFERENCES: ISO/IEC 1539:1991 (E) sections 12.3.2.1 & 14.1.2 EDIT(S): 1. page xvi, last line: change "generic procedure names" to "generic names" 2. section 12.3.2.1.1: change "A given defined operator may,... generic procedure names." to "A given defined operator may,... generic names." 3. section 14.1.2: replace first sentence of third paragraph (beginning "Within a scoping unit, a name...) with "Within a scoping unit, a generic name or defined operator may identify one or more interface blocks (12.3.2.1). Otherwise, 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." 4. section 14.1.2.3: in the first sentence of first paragraph change "generic operator" to "defined operator" 5. section 14.1.2.3: in the first sentence of second paragraph change "generic operator" to "defined operator" 6. section 14.4 in the first paragraph change "generic operator" to "defined operator" 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 -------------------------------------------------------------------------- NUMBER: 000030 TITLE: Length of Character Literals in Array Constructors KEYWORDS: array constructors, character literals, character length DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Consider the following example: CHARACTER :: NAMES(3)*20 NAMES = (/TOM,DICK,HARRY/) This is believed to be illegal. From 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 illegal because the strings have different lengths. Consider another example: CALL SUB (/TOM,DICK,HARRY/) ... SUBROUTINE SUB(NAMES) CHARACTER :: NAMES(:)*(*) WRITE(*,*) LEN(NAMES) ... This also looks illegal. 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? ANSWER: Each character literal constant in an array constructor must be the same length. Both examples are nonstandard conforming. Discussion: The reasoning is correct. The length of a character constant is a type parameter. Therefore, by the cited constraint, all character literal constants in an array constructor must have the same length. This awkwardness 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. REFERENCES: ISO/IEC 1539:1991 (E) section 4.5 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-1 (120.026) HISTORY: 120-LJO-1 (120.074) ----------------------------------------------------------------------- NUMBER: 000031 TITLE: Scope and Type of an implied-DO Variable KEYWORDS: implied-Do variable, DATA statement DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Section 14.1.3 states: The name of the variable that appears as the DO variable of an implied-DO in a DATA statement or an array constructor has a scope of the implied-DO list. It has the type and type parameter that it would have if it were the name of a variable in the scoping unit that contains the DATA statement or array constructor and this type must be integer. Is the following in error since c has type character and therefore does not have type integer: CHARACTER C INTEGER A(10) DATA (A(C), C=1,10)/10*5/ Is the following valid because, although C is a named constant, it has type integer: INTEGER C PARAMETER (C=5) INTEGER A(10) DATA (A(C), C=1,10)/10*5/ Is the following valid: TYPE(ITYPE) CHARACTER FIELD1 INTEGER FIELD2 END TYPE INTEGER A(10) DATA (A(ITYPE), ITYPE=1,10)/10*5/ If itype were a variable it would have type integer and this would be valid. Does the fact that it is the name of a derived type cause a conflict? The second sentence cited above appears to allow: EXTERNAL J INTEGER A(10) DATA (A(ITYPE), ITYPE=1,10)/10*5/ The EXTERNAL statement declares J to be a global name. Since J is a subroutine it has no type, so the presence of the EXTERNAL statement is irrelevant. If J were a function, then it must be type integer for the presence of J in the DATA statement to be valid. Question 1: Is the Fortran 90 standard intentionally extending the FORTRAN 77 standard with respect to implied-DO variables in DATA statements? Did the Fortran 90 standard intentionally delete the material about common block names citeed above? Question 2: Are the conclusions and interpretations above correct or incorrect? If incorrect, for what specific reasons are they incorrect? Question 3: Are the example above standard conforming program fragments? If not, what are the specific reasons? Question 4: Are the rules for implied-DO variables in DATA statements and array constructors exactly the same? If they are not exactly the same, provide examples which illustrate the differences. ANSWER: The first example is in error because C is of type character and R537 requires integer type. The second example is in error. C is of type integer as required by R537 because its type is determined by treating it as if it were a variable in the scoping unit that includes the DATA statement (14.1.3). If C is "treated as a variable" in this context it will have type integer as required but it will also cease to be a variable since C is a named constant in the outer scope. The third example is in error. ITYPE cannot be "treated as a variable" in the context outside the DATA statement because to do so would introduce two local entities in the same class and this is prohibited by 14.1.2. The fourth example is also in error. J cannot be "treated as a variable" in the context outside the DATA statement because to do so would introduce a variable with an external attribute which is prohibited by 5.1. With regard to the specific questions: 1. The Fortran 90 standard intentionally extended the FORTRAN 77 standard with respect to implied-DO variables in DATA statements in only one area: the variable in the outer scope can be an integer array name in Fortran 90 because arrays are also in Fortran 90, unlike FORTRAN 77. It is thought that the material about common block names was intentionally omitted from Fortran 90 because it was redundant. The nature of scoping is such that the implied-DO variable which has a scope of the statement cannot affect interpretation of any object in the surrounding scope with the same name. 2. The detailing of the conclusions and justifications for the examples answer this. 3. The detailing of the conclusions and justifications for the examples answer this. 4. The committee believes that the rules for implied-DO variables in DATA statements and array constructors, with respect to typing and scope are exactly the same. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1, 5.2.9, 14.1.2, & 14.1.3 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-2 (120.027) HISTORY: 120-RRR-1A (120.069A) ----------------------------------------------------------------------- NUMBER: 000032 TITLE: Implicit Declaration of a Derived Type KEYWORDS: derived type, IMPLICIT statement DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Is the following program standard conforming? IMPLICIT TYPE(T1) (A-D) ! Note IMPLICIT range is A-D. TYPE (T1) SEQUENCE CHARACTER*10 NAME INTEGER EMP_NUMBER END TYPE T1 A1%NAME='FRED' ! a1 is implicitly declared to be ! of type t1. ... CONTAINS SUBROUTINE INNER IMPLICIT TYPE(T1) (D) ! D now overrides IMPLICIT for D ! in host. TYPE T1 INTEGER WIDTH INTEGER HEIGHT END TYPE T1 D%WIDTH ! No problem here, d is implicitly ! declared with the t1 that is ! defined in inner. CALL OUTSIDE(C) ! Is this an error? ... Is a reference to A1 (declared in the host) from inside INNER permitted in this example? ANSWER: No, the example is not standard conforming. The fifth constraint to R424 clearly states that: A derived must not be the same as the name of any intrinsic type nor the same as any other accessible derived type . The derived type definition for t1 in inner is illegal because of this constraint. Since the program is nonstandard conforming the second question is moot. However, if the first eight lines of the subroutine inner were replaced by the following: SUBROUTINE INNER INTEGER T1 then this would have the effect of making the type t1 in the host inaccessible, which was the situation envisaged in the question. 4.4.1 states that: If a derived type definition is private, then the type name, the structure value constructor (4.4.4) for the type, any entity that is of the type, and any procedure that has a dummy argument or function result that is of the type are accessible only within the module containing the definition. Although not explicitly stated within the standard, it is intended that the same rule should apply to a derived type definition that is inaccessible for any other reason. Since the derived type t1 is inaccessible in the subroutine inner in the modified example above, the rule implies that any objects of type t1 are also inaccessible in the subroutine inner. Therefore, a reference to a1 is not permitted from inside inner REFERENCES: ISO/IEC 1539:1991 (E) section 4.4.1 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-5 (120.030) HISTORY: 120-TMRE-2 (120.075) ----------------------------------------------------------------------- NUMBER: 000033 TITLE: Interface Blocks with the Same Name in a Program - I KEYWORDS: generic interface blocks, module, USE statement DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: In the following program, even though both interface blocks have the same name and thus might be considered to be merged into a single generic interface block, is function F1 (from MODULE MOD_1) accessible to the program but function F2 (from MODULE MOD_2) hidden? MODULE MOD_1 PUBLIC INT_1 INTERFACE INT_1 ! Generic interface - PUBLIC. INTEGER FUNCTION F1(K) INTEGER K END FUNCTION END INTERFACE INT_1 ... END MODULE MOD_1 MODULE MOD_2 PRIVATE INT_1 INTERFACE INT_1 ! Generic interface, same name - PRIVATE INTEGER FUNCTION F2(L) LOGICAL L END FUNCTION END INTERFACE ... END MODULE MOD_2 PROGRAM EXAMPLE_1 USE MOD_1, MOD_2 ! Program accesses both modules. ... END ANSWER: No. Discussion: Because the name INT_1 is private in the module MOD_2, the interface for the function F2 is accessible in the program EXAMPLE_1, but NOT the generic name INT_1. Therefore, the two interface blocks are NOT merged into a single generic interface block. The function F1 is, therefore, accessible in the program EXAMPLE_1 by either its specific name F1 or the generic name INT_1; the function F2, on the other hand is accessible only by its specific name F2. REFERENCES: EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-6 (120.031) Part 1 HISTORY: 120-TMRE-3 (120.076) ----------------------------------------------------------------------- NUMBER: 000034 TITLE: Interface Blocks with the Same Name in a Program - II KEYWORDS: generic interface blocks, module, USE statement DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: If the following module is added to the example given in NUMBER 000033, and the USE statement in the main program is changed to "USE MOD_1, MOD_2, MOD_3", is the resulting program standard conforming? MODULE MOD_3 PUBLIC INT_1 INTERFACE INT_1 ! Generic interface, same name - PUBLIC. INTEGER FUNCTION F3(L) LOGICAL L END FUNCTION END INTERFACE ... END MODULE MOD_3 ANSWER: Yes, but not for the reason implied by the question. Discussion: The answer in NUMBER 000033 shows that the function F2 (from MODULE MOD_2) does not share the same generic name, INT_1, as the function F1 (from MODULE MOD_1). The new module MOD_3 defines a new interface block INT_1, which will be combined with the identically named interface block from module MOD_1. In the program EXAMPLE_1 the generic name INT_1 has the two specific names F1 and F3. However, since F2 is not part of the combined generic interface block the fact that F2 and F3 have the same dummy argument and result characteristics is of no significance, and the program is standard conforming. REFERENCES: EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-6 (120.031) Part 2 HISTORY: 120-TMRE-3 (120.076) ----------------------------------------------------------------------- NUMBER: 000035 TITLE: Interface Blocks with the Same Name in a Program - III KEYWORDS: generic interface block, module, USE statement DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: If the program and modules shown in NUMBER 000033 are altered so that module MOD_2 USEs MOD_1 and the program EXAMPLE_1 only USEs MOD_2 directly, is this an example of a standard conforming program? If it is standard conforming, does the program have access to function F1 but not F2? ANSWER: Yes, the program is standard conforming. Discussion: Within module MOD_2 the two generic interface blocks are combined into a single interface block. However, since INT_1 is declared to be private within module MOD_2 only the specific names of the functions F1 and F2 are accessible to program units using MOD_2 (c.f. NUMBER 000033). Therefore, both the function F1 and F2 are accessible within the program EXAMPLE_1, but only by their specific names. REFERENCES: EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-6 (120.031) Part 3 HISTORY: 120-TMRE-3 (120.076) ----------------------------------------------------------------------- NUMBER: 000036 TITLE: Pointer to an Assumed-size Array KEYWORDS: pointer, assumed-size array, pointer assignment statement DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Is a pointer assignment statement of the form: PTR => A where A is an assumed-size array, standard conforming? ANSWER: No. This is prohibited by section 6.2.1, second paragraph, second sentence. REFERENCES: ISO/IEC 1539:1991 (E) section 6.2.1 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-7 (120.032) HISTORY: 120-RRR-2A (120.087A) ----------------------------------------------------------------------- NUMBER: 000037 TITLE: Use of Array Sections in Pointer Assignment Statements KEYWORDS: pointer assignment statement, array sections, pointer DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: If A is an assumed-size array: Is "PTR => A(:N)" standard conforming? Are "PTR => A(:)" and "PTR => A(N:)" standard conforming? ANSWER: "PTR => A(:N)" is standard conforming because A(:N) is a valid array section. Forms "PTR => A(:)" and "PTR => A(N:)" are not standard conforming because the array sections are prohibited by the second constraint after R621. REFERENCES: ISO/IEC 1539:1991 (E) section 6.2.2 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-7 (120.032) HISTORY: 120-RRR-2A (120.087A) ----------------------------------------------------------------------- NUMBER: 000038 TITLE: Same Interface Body in Multiple Generic Interface Blocks KEYWORDS: interface body, generic interface blocks, scoping unit DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Part 1. Is the form of the following example standard conforming? That is, can the same interface body exist in multiple generic interface blocks that are all accessible from a single scoping unit. MODULE MOD_1 INTERFACE RED SUBROUTINE CMN(K) INTEGER K END SUBROUTINE SUBROUTINE S(X) REAL X END SUBROUTINE END INTERFACE END MODULE MODULE MOD_2 INTERFACE BLUE SUBROUTINE SS(Y) REAL Y END SUBROUTINE SUBROUTINE CMN(K) INTEGER K END SUBROUTINE END INTERFACE END MODULE PROGRAM EXAMPLE_1 USE MOD_1, MOD_2 INTEGER M ... CALL RED(M) ... CALL BLUE(M) ... END PROGRAM Part 2. If the names are removed from the interface blocks in both modules, thus making them nongeneric, and the subroutine calls in program EXAMPLE_1 replaced by "CALL CMN(M)", is the resulting program standard conforming? That is, may a procedure interface description occur in multiple nongeneric interface blocks that are accessible to a given scoping unit and may the program unit reference that procedure? ANSWER: Part 1. No. The example is not standard conforming. Part 2. No. Discussion: The last sentence of the second paragraph of 12.3.2.1 states A procedure must not have more than one explicit specific interface in a given scoping unit. In the example the subroutine CMN has two specific interfaces, one from each module in the program EXAMPLE_1 which is forbidden. The program could be made standard conforming by making the name CMN private in one or both modules. REFERENCES: ISO/IEC 1539:1991 (E) section 12.3.2.1 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-8 (120.033) HISTORY: Original interpretation in 120-TMRE-4 (120.077) Questioned in X3J3/92-131 Approved as X3J3/92-174 at meeting 122 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: Interpretation 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, ext.) 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. Future revisions of the standard should explicitly state the semantics of associating pointer actual arguments with nonpointer dummy arguments in the section which describes arguments associated with dummy objects (12.4.1.1). This section should also state pointer actual arguments may be associated with pointer or nonpointer dummy arguments, and additional examples should be added for clarity. 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 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-9 (120.034) HISTORY: 120-JLS-9 (120.079) ----------------------------------------------------------------------- NUMBER: 000040 TITLE: Allocation of Arrays of Pointers KEYWORDS: arrays, pointer allocation, structures DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following code fragment: TYPE DEF INTEGER I INTEGER, POINTER :: PTR END TYPE TYPE (DEF) :: STRUCT (5) ... ALLOCATE (STRUCT%PTR) Are the following quotations from the standard sufficient to declare this code fragment to be nonstandard-conforming? o The constraint immediately following R628 "Each must be a pointer or an allocatable array." o The second sentence of the fourth constraint after R613 "A to the right of a with nonzero rank must not have the POINTER attribute." ANSWER: The ALLOCATE statement in the example is not permitted by the syntax rules and constraints of the standard: R625 is or R614 is R612 is [%] R613 is [()] Constraint: A to the right of a with nonzero rank must not have the POINTER attribute. REFERENCES: ISO/IEC 1539:1991 (E) sections 6.1.2 and 6.3.1 EDIT(S): None. SUBMITTED BY: Larry Rolison, X3J3/92-056 HISTORY: Approved as X3J3/92-069 at meeting 121 ----------------------------------------------------------------------- NUMBER: 000041 TITLE: Procedure with Target Dummy Argument Requires Explicit Interface KEYWORDS: dummy argument, explicit interface, TARGET attribute DEFECT TYPE: Interpretation 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: To aid optimization of the subprogram which calls the procedure and to aid in error detection. 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. 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 with the target dummy argument. REFERENCES: ISO/IEC 1539:1991 sections 6.3.3.2, 12.3.1.1, and C.5.3 EDIT(S): None. SUBMITTED BY: K. Kazumura, X3J3/92-048 (121-ADT-8) page 23 HISTORY: Posted request to f90 interp e-mail Approved as X3J3/92-070 meeting 121 -------------------------------------------------------------------------- NUMBER: 000042 TITLE: KIND parameter value KEYWORDS: kind parameter value, representation of constants DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: It is stated in section 5.1.1.2 that: An entity declared with type specifier REAL(KIND(0.0)) is of the same kind as one declared with the type specifier REAL. There are similar statements about INTEGER, DOUBLE PRECISION, and COMPLEX type specifiers in sections 5.1.1.1, 5.1.1.3, and 5.1.1.4. In section 5.1.1.2, for example, must the constant be exactly the characters "0.0" to cause the declared entity to be the same as the default real entity? Could the result be different if the constant were expressed, for example, as "0."? It appears that the committee chose the value 0 in these statements because it exists on every machine on which a Fortran 90 processor will be run. Further, a specific value was chosen so that machine architecture differences would be factored out. For example, KIND(10000000.) might have the same kind parameter value as default real on one machine but not on another. ANSWER: No, the constant need not be exactly "0.0". The constant "0.0" is used only as an example. Discussion: The KIND intrinsic is defined in section 13.13.51 of the standard to return a value equal to the kind type parameter of its argument; the argument may be of any intrinsic type. In section 13.5.5 it is stated that the value of the argument to this function need not be defined. It is only the kind type of the argument that is relevant. Nowhere in the standard is there a restriction that the argument to the KIND intrinsic be a constant at all, much less the specific constant 0.0. The is specified in section 5.1, R505 to be a . The definition of an is given in section 7.1.6.1, and the restrictions on the argument of the KIND intrinsic in an are detailed in item (6) of that definition. The question makes the assertion that KIND(10000000.) might not have the same kind parameter value as default real on all machines. This assertion is false. Possibly the requestor believed that a literal real constant could assume a kind parameter value based on the number of digits in the constant or some other implicit criterion. This is not allowed in Fortran 90. In section 4.3.1.2, it is explicitly stated that: A literal real constant without a kind type parameter is a default real constant if it is without an exponent part..." Similar arguments apply to the corresponding questions about INTEGER, DOUBLE PRECISION, and COMPLEX type specifiers. REFERENCES: ISO/IEC 1539:1991, sections 4.3.1.2, 5.1, 5.1.1, 7.1.6.1, 13.5.5, & 13.13.51 EDIT(S): None. SUBMITTED BY: L.R.Rolison, X3J3/92-060 HISTORY: Approved as X3J3/92-084 at meeting 121 by a vote of 19-0 -------------------------------------------------------------------------- NUMBER: 000043 TITLE: List-directed character input KEYWORDS: list-directed, input, character, zero length, null value DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: For list directed input of character items, how does the standard distinguish between the input of an undelimited zero-length character string and a null value? If the input is a zero-length character string, the corresponding list item must be set to blank, whereas if the input is a null value, the definition status of the corresponding list item must be left unchanged. However, there appears to be no way to distinguish these two possibilities. ANSWER: The ambiguity between undelimited zero length character values and the null value should be resolved by requiring that zero-length character values always be delimited in list-directed input. Discussion: Several other potential ambiguities with undelimited character items in list-directed input were resolved in section 10.8.1 by requiring delimiters in those cases. However, the case of a zero- length string was omitted from this list. EDIT(S): The following changes should be made to section 10.8.1, 1. Add " and" to the end of item (4), and 2. Add an additional item to the list after item (4): "(5) The character constant contains at least one character," REFERENCES: ISO/IEC 1539:1991, sections 10.8.1, 10.8.1.1 SUBMITTED BY: Richard E. Maine, X3J3/92-087 HISTORY: Approved as X3J3/92-116 at meeting 121 by a vote of 19-0 -------------------------------------------------------------------------- NUMBER: 000044 TITLE: END Statement and Fixed Form Source KEYWORDS: end statement, fixed form source, initial line DEFECT TYPE: Amendment STATUS: X3J3 draft response QUESTION: Consider the following: 1. Section 3.3.2.4 "Fixed Form Statements", page 24, requires that no statement, except the program unit END statement, have an initial line that appears to be a program unit END statement. 2. Other statements, for example, , R1218 page 175, may consist of only the keywords "END" or "END FUNCTION". While these do not conflict, the combined requirements are not obvious, sometimes requiring unnatural acts by users. Consider, for example, ending an for a function subprogram: 1. END !wrong, appears to be a program unit END 2. EN !END continued to 2nd line. OK & D 3. END FUNCTION !OK in main PROGRAM unit and SUBROUTINE !subprogram, wrong in FUNCTION subprogram 4. EN !OK & D FUNCTION 5. END F !OK 6. END FUNCTION A !OK in main program, OK in SUBROUTINE & BC !subprogram, OK in function if name !is not "A" ANSWER: Section 3.3.2.4 was brought forward from FORTRAN 77 without modification for new Fortran 90 constructs. The resulting usability characteristics, as seen in the examples above, are regrettable enough that a repair should be made. REFERENCES: ISO/IEC 1539:1991 (E) section 3.3.2.4 EDIT(S): In 3.3.2.4 replace the text "and no other statement in the program unit may have an initial line that appears to be a program unit END statement" with ". A statement whose initial line appears to be a program unit END statement must not be continued." SUBMITTED BY: J.C.Shepherd, X3J3/92-012, X3J3/92-013, X3J3/92-014 HISTORY: Approved as X3J3/92-088A at meeting 122 by a vote of 24-0 ----------------------------------------------------------------------- NUMBER: 000045 TITLE: Array Intrinsics with Arrays of Derived-type Arguments KEYWORDS: array intrinsics, derived-types, operations, interface blocks DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: The intrinsic functions ALLOCATED, ASSOCIATED, LBOUND, UBOUND, PRESENT, SHAPE, SIZE, MERGE, PACK, SPREAD, UNPACK, CSHIFT, EOSHIFT, TRANSPOSE, RESHAPE, and TRANSFER are documented as accepting arrays of any type. Does this include arrays of derived-type, and if so, does this conflict with section 4.4.5 which states: Any operation on derived-type entities or nonintrinsic assignment for derived-type entities must be defined explicitly by a function or subroutine and a procedure interface block. ANSWER: The intrinsics in question can accept arguments which are arrays of derived-types. This does not conflict with section 4.4.5. Discussion: The term "operation" in section 4.4.5 refers to user defined infix unary and binary operations in expressions and nonintrinsic assignments. Such operators are defined by means of interface blocks which define operators and nonintrinsic assignment. Using an object as an actual argument in a procedure reference is not considered an operation on that object in this sense. REFERENCES: ISO/IEC 1539:1991 section 4.4.5 and 13.13 X3J3/92-051 pages 13-14 EDIT(S): None. SUBMITTED BY: H.Funaki, X3J3/92-051 (121-ADT-11) pp13-14 HISTORY: Posted request to f90 interp e-mail Approved as X3J3/92-092A meeting 121 by a vote of 19-0 ----------------------------------------------------------------------- NUMBER: 000046 TITLE: RESULT clause for RECURSIVE functions KEYWORDS: result clause, recursive functions DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: 1. Does RECURSIVE require RESULT? 2. Assuming (1), is a permitted on the function name when RECURSIVE is present? ANSWER: The RESULT clause is not required for all RECURSIVE functions; it is required for those that directly recurse. That is, the RESULT clause is necessary to make the function visible in its own body so that direct recursion can take place. It should be noted that the prohibition against typing the function name when a result variable name is specified was not intended to prohibit putting the function type into the header. In other words: FUNCTION F() RESULT (FVAR) INTEGER FVAR and INTEGER FUNCTION F() RESULT (FVAR) are both allowed. The case prohibited is: FUNCTION F() RESULT (FVAR) INTEGER F It is possible for both a and RECURSIVE to appear in a single function header. REFERENCES: ISO/IEC 1539:1991 (E) section 12.5.2.2 EDIT(S): None. SUBMITTED BY: L.Meissner, X3J3/92-045 (121-ADT-5) p17. HISTORY: For discussion see X3J3/92-45 (121-ADT-5) pp 18, 26-27 Approved as X3J3/92-101 at meeting 121 by a vote of 20-0 ----------------------------------------------------------------------- NUMBER: 000047 TITLE: Automatic data object in initialization expressions KEYWORDS: automatic data object, initialization expressions DEFECT TYPE: Amendment STATUS: X3J3 draft response QUESTION: Can an automatic data object be used as the argument to the LEN function in the initialization expression of a PARAMETER statement or an item given the PARAMETER attribute? ANSWER: It was the intent of the committee to include objects with non constant lengths in the restrictions on the LEN function in section 7.1.6.1 (pages 77 and 78). REFERENCES: ISO/IEC 1539:1991 (E) section 7.1.6.1 EDIT(S): 1. Section 7.1.6.1, page 77, item (6) change "not assumed or" to "not assumed, are not defined by an expression that is not a constant expression, and are not" 2. Section 7.1.6.1, page 78, item (6) change "not assumed or" to "not assumed, are not defined by an expression that is not a constant expression, and are not" SUBMITTED BY: 120.042 HISTORY: For discussion see 120.073A and X3J3/92-036 (121-JKR-4) Approved as X3J3/92-107 at meeting 121 by a vote of 20-0 -------------------------------------------------------------------------- NUMBER: 000048 TITLE: Pointer-valued statement functions KEYWORDS: statement function, pointer DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Can a statement function be pointer-valued? There appears to be nothing in section 12.5.4 to prohibit this. ANSWER: No, a statement function cannot be pointer-valued. Discussion: From section 12.3.1: The interface of a statement function is always implicit. >From section 12.3.1.1: A procedure must have an explicit interface if... (2) The procedure has: (e) A result that is a pointer (functions only) Therefore, a statement function cannot have a result that is a pointer. REFERENCES: ISO/IEC 1539:1991 sections 12.3.1, 12.3.1.1, 12.5.4 EDIT(S): None. SUBMITTED BY: L.Meissner, X3J3/92-45 (121-ADT-5) p37 HISTORY: Approved as X3J3/92-108 at meeting 121 by a vote of 19-0 -------------------------------------------------------------------------- NUMBER: 000049 TITLE: Characteristics of Function Results KEYWORDS: characteristics, function result, ENTRY, exact dependence, partially associated DEFECT TYPE: Amendment STATUS: X3J3 draft response QUESTION: Given a character function with an ENTRY statement, both results must have the same characteristics or be scalars without the POINTER attribute and have identical length. Therefore: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN,ENT ... ENTRY ENT(M,N) ... END FUNCTION is standard conforming. Q1. FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=M+N)::ENT ... ENTRY ENT(M,N) ... END FUNCTION Is the code above standard conforming? Q2. FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=N+M)::ENT ... ENTRY ENT(M,N) ... END Is the code above standard conforming? Q3. FUNCTION FUN(M) CHARACTER (LEN=M+M)::FUN CHARACTER (LEN=M*2)::ENT ... ENTRY ENT(M) ... END Is the code above standard conforming? Q4. What is the meaning of the phrase "the exact dependence on the entities" in section 12.2.2? ANSWER: Q1. Yes Q2. Yes Q3. Yes Q4. The phrase "the exact dependence on the entities" in section 12.2.2 refers to run-time values, which may or may not be known at compile- time. The requirement "must...be of type default character with identical length" is a requirement for a standard-conforming program. Since it is not a constraint, a processor is not required to detect a violation of this requirement even if the lengths are known at compile- time, though it may do so. Discussion: If the length of a function result of type default character cannot be determined at compile-time, a processor may assume that the lengths specified for each result are the same. Therefore, the following code is standard conforming: FUNCTION FUN(K) CHARACTER (LEN=K)::FUN CHARACTER (LEN=J)::ENT ... ENTRY ENT(J) ... FUN="HELLO" ... END FUNCTION When it is invoked by the statement: GREETING=ENT(5) FUN has a length of 5. Given the definition of "partially associated" in section 14.6.3.3 Two scalar entities are partially associated if they are associated without being totally associated. the last sentence on page 248: For character entities, partial association may occur only through argument association, or the use of COMMON, EQUIVALENCE, or ENTRY statements. is incorrect. There is no way that partial association for character entities may occur through the use of an ENTRY statement. REFERENCES: ISO/IEC 1539:1991 (E) section 12.2.2 & 14.6.3.3 EDIT(S): In the last line on page 248 change "COMMON, EQUIVALENCE, or ENTRY statements" to "COMMON, or EQUIVALENCE statements". SUBMITTED BY: Y.Yoshida, X3J3/92-051 (121-ADT-11) pp11-13 HISTORY: Approved as X3J3/92-109A at meeting 121 by a vote of 19-0 -------------------------------------------------------------------------- NUMBER: 000050 TITLE: Repeat counts on edit descriptors KEYWORDS: edit descriptor, repeat count DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Is the repeat specification part of the edit descriptor? Discussion: In section 10.1.1 the second constraint states that the comma separating the in a is optional between certain combinations of edit descriptors. In section 10.2 a format-item is defined as, amongst other things, "[r]" and in 10.2.1 an edit-descriptor can be a data- edit-desc. However, data-edit-desc does not contain the repeat count. This implies that: 100 FORMAT(1PE20.10) !is legal 200 FORMAT(1P3E20.10) !is not legal 300 FORMAT(1P,3E20.10) !is legal ANSWER: The repeat count is not part of any edit descriptor except the "[r]/" edit descriptor. The comments in the examples are correct. REFERENCES: ISO/IEC 1539:1991, sections 10.1.1, 10.2, & 10.2.1 EDIT(S): None. SUBMITTED BY: A.D.Tait, X3J3/92-041 (121-ADT-1) HISTORY: X3J3/92-041, X3J3/92-042 This problem appears to stem from an incompatibility between FORTRAN 66 and FORTRAN 77. In FORTRAN 66 a FORMAT statement is of the form: FORMAT(list) where the list consists of a series of field descriptors separated by field separators and optionally preceded and succeeded by slashes. The field descriptors for real or double precision values consisted of the now familiar Dw.d, Ew.d, Fw.d, and Gw.d edit descriptors (a term introduced in FORTRAN 77) preceded by an optional scale factor and repeat count. For example, in FORTRAN 66 a valid field descriptor is 1P3E17.10, where 1P is the scale factor, 3 the repeat count for a field containing 10 digits in the fractional part of the number and having a E exponent. In FORTRAN 77 the scale factor is an edit descriptor and thus is a list element in the format specification. While FORTRAN 77 specifies places where the commas separating list elements in a format specification are optional, it fails to make a comma between the scale factor and an immediately succeeding repeated D, E, F, or G edit descriptor optional. This situation has been carried over to Fortran 90. Thus: 100 FORMAT(1PE20.10) !is legal in F66, F77, and F90 200 FORMAT(1P3E20.10) !is legal in F66, and illegal in F77 & F90 300 FORMAT(1P,3E20.10) !is illegal in F66, and legal in F77 & F90 -------------------------------------------------------------------------- NUMBER: 000051 TITLE: On Unambiguous generic procedure references KEYWORDS: generic procedure DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Should the rules in 14.1.2.3 include a rule that uses the fact that a dummy argument is either a subroutine or a function to disambiguate a generic procedure reference? For example, such a rule could be on page 242, line 40, after "with a different type" adding "present as a subroutine instead of a function". ANSWER: No. The intent of the committee was to keep the rules as simple as possible in order that they would be easy to understand and to use. It is not always possible for the processor to tell whether an actual argument that is a procedure is a subroutine or an implicitly typed function. REFERENCES: ISO/IEC 1539:1991 (E) section 14.1.2.3 EDIT(S): None. SUBMITTED BY: John Reid, SC22/WG5 N786A HISTORY: X3J3/92-017 at meeting 121 - RFI: generic interfaces and dummy procedure arguments -------------------------------------------------------------------------- NUMBER: 000052 TITLE: Expressions in Statement Function Definitions KEYWORDS: statement functions, array, variable, intrinsic operator, expression DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 12.5.4 appears to prohibit whole array names appearing as actual arguments to functions within the of a statement function. The first constraint states: The may be composed only of constants (literal and named), references to scalar variables and array elements, references to functions and function dummy procedures, and intrinsic operators. A defined operator may be an extended intrinsic operator, as well as a defined unary or binary operator. Question 1: Is the legal FORTRAN 77 program fragment, EXTERNAL FCN REAL A(2) STFN(X) = FCN(A) + X where FCN is some function and STFN is a statement function, a legal Fortran 90 program fragment? Question 2: Is it intended that a defined operator which is an extended intrinsic operator be allowed in a statement function definition but other defined operators not be allowed? ANSWER: The intent is that the program fragment in question one should be a valid Fortran 90 program fragment, and that no defined operators be allowed in a statement function definition. The standard is in error. The edits below should be applied to correct the standard. Discussion: The intent of the standard was to retain the FORTRAN 77 definition of statement functions without extending it to include defined operators or array expressions. In FORTRAN 77, "expression" and "variable" referred only to scalar expressions and variables; there were no defined operators. In Fortran 90 these terms also refer to array expressions and arrays. The Fortran 90 definition of statement functions was intended to prohibit array expressions but overlooked the use of an array name as an actual argument to a function in the definition of a statement function. REFERENCES: ISO/IEC 1539:1991 section 12.5.4 EDIT(S): Section 12.5.4 1. First constraint, first sentence change "references to scalar variables and array elements" to "references to variables" change "intrinsic operators" to "intrinsic operations" after first sentence add If contains a reference to a function or a function dummy procedure it must not require an explicit interface or be a transformational intrinsic, and its result must be scalar. If an argument to a function or a function dummy procedure is array valued, it must be an array name." 2. Second constraint, third sentence change "scalar variable, array element" to "variable" 3. Fifth constraint, first sentence delete second word ("scalar") SUBMITTED BY: A. D. Tait X3J3/92-064 item # 13 points to B. Smith e-mail in X3J3/92-045 pp. 50-52 HISTORY: Approved as X3J3/92-153A at meeting 122 by a vote of 17-2 -------------------------------------------------------------------------- NUMBER: 000053 TITLE: Optional Intrinsic Function Arguments KEYWORDS: intrinsic functions, optional arguments DEFECT TYPE: Amendment STATUS: X3J3 consideration in progress QUESTION: Should constraining text be added to the description of optional argument Y in CMPLX, and optional argument BACK in INDEX, and optional argument SIZE in ISHFTC, and optional argument A3,... in MAX, and optional argument A3,... in MIN, and optional argument BACK in SCAN, and optional argument BACK in VERIFY to state that the argument must not be an optional argument of an invoking procedure? ANSWER: In principle yes; however it is more appropriate to add an additional restriction on dummy arguments not present in section 12.5.2.8. Discussion: The standard contains numerous restrictions intended to ensure that the rank of a given expression never changes. The case of elemental functions with optional arguments was inadvertently overlooked. Consider the following subprogram: SUBROUTINE SUB (A,B,C) INTEGER :: A ,B INTEGER, OPTIONAL :: C (:) PRINT *, MAX (A, B, C) END When C is present, the result of the elemental function MAX, is an array of the same shape as C. However, if SUB were to be called with the third argument omitted, the result would be a scalar. The supplied edit remedies this deficiency. REFERENCES: ISO/IEC 1539:1991 (E) 12.5.2.8, 13.13.20, 13.13.46, 13.13.50, 13.13.52, 13.13.63, 13.13.68, 13.13.91, 13.13.111, 13.13.113. EDIT(S): 1. Add the following point to the numbered list in section 12.5.2.8: (5) If it is an array, it must not be supplied as an actual argument to an elemental procedure unless an array of the same rank is supplied as an actual argument corresponding to a nonoptional dummy argument of that elemental procedure. 2. In the paragraph following the numbered list, replace "It" with "Except as noted in (5) above, it" SUBMITTED BY: response to X3J3/92-058 (121-LRR-5) HISTORY: Submitted as question in 92-058, draft response prepared in X3J3/92-094, and in N815A of the WG5 Victoria meeting based on John Reid's paper, N786A. -------------------------------------------------------------------------- NUMBER: 000054 TITLE: Resolving Generic Procedure References KEYWORDS: generic, interface, intrinsic DEFECT TYPE: Interpretation Status: X3J3 consideration in progress QUESTION: Consider the following code fragment: PROGRAM HOST DIMENSION ABS(10) ... CONTAINS SUBROUTINE SUB() INTERFACE ABS FUNCTION IA1(I) INTEGER IA1, I END FUNCTION END INTERFACE R = ABS(1.5) Do the rules for resolving references to names established to be generic (14.1.2.4.1) imply that R will be assigned the value 1.5 as the result of invoking the intrinsic ABS? ANSWER: Yes. Discussion: ABS is established to be generic in the scope of subroutine SUB (14.1.2.4 item 1(a)). The rules in section 14.1.2.4.1 can be used to resolve the procedure reference. Rule (1) in 14.1.2.4.1 does not apply, as the reference is not consistent with any specific interface in the interface block with the name ABS. Rule (2) does not apply as ABS does not appear in an INTRINSIC statement. Rule (3) does not apply as ABS is not established to be generic in the host scope. Therefore, rule (4) is applied and the reference is resolved to the generic intrinsic procedure ABS. REFERENCES: ISO/IEC 1539:1991(E) Sections 14.1.2.4 and 14.1.2.4.1 SUBMITTED BY: J.C. Shepherd HISTORY: One of the questions raised in X3J3/92-048 pg 29-30, 34-40, 51, 52 and X3J3/92-052 pg 1-3. Initially drafted as X3J3/92-119 -------------------------------------------------------------------------- NUMBER: 000055 TITLE: Characteristics of character function results KEYWORDS: character function, function result DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: In section 12.5.2.5 the second paragraph after the constraints contains the text: "Otherwise, they are storage associated and must all be scalars without the POINTER attribute and all be of type default character with identical length". Is some of this text redundant? ANSWER: Yes. Discussion: The phrase referring to "identical length" was meant to include the FORTRAN 77 character storage association case. FORTRAN 77 requires either that they all be of assumed length or all be of the same constant length; both are included as characteristics that agree in section 12.5.2.5 in the second paragraph after the constraints that starts with "If the ENTRY". The phrase is redundant and is causing confusion. REFERENCES: ISO/IEC 1539:1991 (E) section 12.5.2.5. EDIT(S): In Section 12.5.2.5 in the sentence that starts: "Otherwise, they ... " delete: "all be scalars ... length or". SUBMITTED BY: J.K.Reid in N786A at the WG5 Victoria Meeting, July 1992. HISTORY: Drafted at the WG5 Victoria Meeting July, 1992 and submitted to X3J3 at meeting 122 -------------------------------------------------------------------------- NUMBER: 000056 TITLE: TRANSFER intrinsic function description KEYWORDS: Intrinsic functions, examples DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Should the text of Case (iii) under Examples in the TRANSFER intrinsic function be corrected so the example reads: Case (iii): TRANSFER((/1.1,2.2,3.3/),(/ (0.0,0.0) /),1) is a complex rank-one array of length one whose sole element has the value (1.1,2.2)." ANSWER: Yes. Discussion: The current format of the example, 1.1+2.2i, while valid mathematical notation for complex type, should be changed to an ordered pair of real numbers used consistently elsewhere in the standard for complex type numbers. REFERENCES: ISO/IEC 1539:1991 (E) Section 13.13.108. EDIT(S): Correct the text of Case (iii) under Examples in the TRANSFER intrinsic function so that the example reads: Case (iii): TRANSFER((/ 1.1,2.2,3.3 /),(/ (0.0,0.0) /),1) is a complex rank-one array of length one whose sole element has the value (1.1,2.2)." SUBMITTED BY: Larry Rolison in X3J3/92-059 (121-LRR-6) HISTORY: Submitted as a request in X3J3/92-059, Draft response first prepared in x3j3/92-091 later drafted interpretation in X3J3/92-159 -------------------------------------------------------------------------- NUMBER: 000057 TITLE: Prohibition against multiple explicit specific interfaces KEYWORDS: specific interfaces, interface body, interface block DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Could you provide an example of code that is prohibited by the statement "a procedure must not have more than one explicit specific interface in a given scoping unit" in 12.3.2.1 and that would not be prohibited by some other provision of ISO/IEC 1539:1991? What is the meaning and/or intent of the following sentence in 12.3.2.1? A procedure must not have more than one explicit specific interface in a given scoping unit." Multiple SPECIFIC interfaces can not be produced by the existence of interface blocks because the definition of an interface body states that it only specifies an EXPLICIT interface, not a SPECIFIC interface. If the statement in 12.3.2.1: "An external or module subprogram definition specifies a specific interface for the procedures defined in that subprogram.", only external or module subprograms have specific interfaces and the specific interfaces are only specified by the text of the subprogram itself. ANSWER: Your statement is incorrect, and an example follows. Discussion: The paragraph following the constraints, in 12.3.2.1 is concerned with "specific interfaces" and the reader was intended to understand from the context in that discussion that an interface specified by an interface body be both specific and explicit. See also 14.1.2.4, (2), (a) which shows that it was intended that an interface body define a specific interface. To answer your question, the intention was to disallow the same information being provided twice, as for other specifications. An example of the statement that prohibits more than one explicit specific interfaces follows: Example: MODULE MOD INTERFACE SUBROUTINE SUB(I,J) INTEGER I,J END SUBROUTINE SUBROUTINE SUB(M,N) INTEGER M,N END SUBROUTINE END INTERFACE END MODULE REFERENCES: ISO/IEC 1539:1991 (E) section 12.3.2. EDIT(S): Section 12.3.2.1, the sentence that begins "An interface body..." change "explicit interface" to "explicit specific interface". SUBMITTED BY: L. Rolison HISTORY: 120.035, 120.090 Approved as X3J3/92-162A at meeting 122 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. 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, 1st pp, 1st 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, 1st pp, 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, 2nd pp 1st 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, 1st pp, 3rd line [160:29] change "keywords" to "argument keywords" 8. Page 168, the pp following the line "END INTERFACE", 2nd 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 "keyword" to "argument keyword" 10. Page 183, section 13.3, 1st pp, 3rd line, 2 occurrences [183:38] change "keyword" to "argument keyword" 11. Page 188, section 13.10, 1st pp, 1st two lines, 2 occurrences [188:12,13] change "keyword" to "argument keyword" 12. 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". SUBMITTED BY: GEN HISTORY: WG5/N808, Question 2. Approved as X3J3/92-164A at meeting 122 by a vote of 17-4 -------------------------------------------------------------------------- NUMBER: 000059 TITLE: SEQUENCE derived type and component bounds KEYWORDS: SEQUENCE, derived type DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Given two objects of SEQUENCE derived type, can the two objects be of the same derived type if the only difference between the two SEQUENCE derived type definitions is the value of the low bound and high bound for one dimension of one of the components (assuming the extent of the dimension of the array component matches the extent given in the other; and there are no structure components that have PRIVATE accessibility)? The description of when two objects of SEQUENCE derived type have the same type includes the words (2nd paragraph of 4.4.2 "Determination of derived types") "have structure components that do not have PRIVATE accessibility and agree in order, name, and attributes". This text seems to imply that if the derived type includes an then the individual low bounds and high bounds have to be the same. An example that corresponds to the question above: SUBROUTINE S() TYPE T SEQUENCE INTEGER A(1:10) END TYPE TYPE (T) X CALL S2(X) ... SUBROUTINE S2(Y) TYPE T SEQUENCE INTEGER A(2:11) END TYPE TYPE (T) Y ... Do X and Y have the same type? ANSWER: No. Discussion: The attributes that a data object may have are enumerated in section 5.1.2. Included in these is the DIMENSION attribute (section 5.1.2.4). In reference to the explicit shape arrays in the example above, in order for the attributes to agree, the values of the corresponding lower bounds and the corresponding upper bounds in must be equal. REFERENCES: ISO/IEC 1539:1991(E) 5.1.2 EDIT(S): None. SUBMITTED BY: Janice C. Shepherd X3J3/92-129 HISTORY: X3J3/92-129 Approved as X3J3/92-165A at meeting 122 by a vote of 19-2 -------------------------------------------------------------------------- NUMBER: 000060 TITLE: Statement function argument references KEYWORDS: statement function arguments DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following program: INTEGER AR EXTERNAL AR REAL A(2), FUN, X, Y DATA A/2*5./ FUN(X) = X+X+X Y=FUN(A(AR(5))) END INTEGER FUNCTION AR(I) INTEGER I AR = 1 PRINT *,I RETURN END When the statement function is referenced, how many times is the function AR called? Or, to put it another way, how many times is the PRINT statement in function AR executed during the statement function reference? ANSWER: In the program above, the function AR is called once. Therefore, the PRINT statement in function AR is executed once. Discussion: When the statement function is referenced, the actual arguments are evaluated and the resulting values are associated with the corresponding dummy arguments. The statement function FUN has only one actual argument which contains only one reference to the external function AR. Therefore, the function AR is called once as part of the evaluation of the actual argument. The value resulting from this evaluation is associated with the single dummy argument of the statement function FUN. REFERENCES: ISO/IEC 1539:1991 (E) sections 12.5.4, the fourth paragraph after the last constraint. EDIT(S): None. SUBMITTED BY: Linda J. O'Gara HISTORY: 121-LJO-3, 121-ADT-11 pages 14-17 Approved as X3J3/92-168 at meeting 122 by a vote of 17-0 -------------------------------------------------------------------------- NUMBER: 000061 TITLE: G edit descriptor with "d" = 0 KEYWORDS: G edit descriptor DEFECT TYPE: Amendment STATUS: X3J3 draft response QUESTION: Is a value of 0 for "d" in a G edit descriptor (e.g. 1PG8.0) permitted? ANSWER: Yes. See R1008, R1005, and R404. QUESTION: Did the committee mean to change the definition of G format in Fortran 90 (compared to FORTRAN 77)? ANSWER: Yes. The form of output text produced by the G edit descriptor for some values and particular edit descriptors was intentionally changed. The changes require processors to give meaningful output instead of "*"s for certain values and edit descriptors. QUESTION: What happens when N (the value to be printed) is zero and "d" is zero? ANSWER: The standard indicates a format of F(w-n).-1 is to be used. This is an error in the standard. REFERENCES: ISO/IEC 1539:1991 (E) Rules R404, R1005, and R1008 EDIT(S): 1. In section 10.5.4.1.2 second paragraph, 3rd sentence, after "-0.5," add " or N is identically 0 and d is 0,". 2. In section 10.5.4.1.2, second paragraph, fourth sentence, after "N is identically 0" add " and d is not zero". 3. In section 1.4.1, add item (5) as follows: (5) A value of 0 for a list item in a formatted output statement will be formatted in a different form for most G edit descriptors. In addition, the Fortran 90 standard specifies how rounding of values will affect the output field form, but FORTRAN 77 did not address this issue: therefore, some FORTRAN 77 processors may produce a different output form than Fortran 90 processors for certain combinations of values and G edit descriptors. SUBMITTED BY: J.Brixius, 121-JB-1 HISTORY: 121-ADT-7 pp 1-9, 92-076, 92-118 Approved as X3J3/92-149A at meeting 122 by a vote of 20-3 -------------------------------------------------------------------------- NUMBER: 000062 TITLE: Statement function constraints KEYWORDS: statement function, host association DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Does the last constraint under R1226 allow variables in a of a statement function definition to be accessed via host association or use association? PROGRAM HOST INTEGER I ... CONTAINS SUBROUTINE INNER() STMTFUNC()=I+1 ... ANSWER: Yes. Discussion: It was the intent of the committee to allow variables made accessible by use or host association to appear in a of a statement function definition. The text of the last constraint under R1226 needs clarification to better reflect that intent. REFERENCES: ISO/IEC 1539:1991 (E) section 12.5.4 EDIT(S): In the last constraint after R1226 in section 12.5.4 replace "local to" with "accessible in". SUBMITTED BY: J.C.Shepherd X3J3/92-015 HISTORY: Discussed in X3J3/92-046 pp 28-29 Initially drafted as X3J3/92-120 Approved as X3J3/92-160 at meeting 122 by a vote of 23-0 -------------------------------------------------------------------------- NUMBER: 000063 TITLE: Interfaces and dummy procedure arguments KEYWORDS: interface, dummy procedure DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Given a procedure that has a dummy argument, must an explicit interface for the procedure show sufficient information to indicate that its dummy argument is a dummy procedure? ANSWER: Yes. Discussion: The first sentence of the second paragraph in 12.3.2.1 indicates that an interface body must specify all of the procedures characteristics. Section 12.2 indicates that a procedure's characteristics include the characteristics of its arguments. Therefore, an interface body must include an EXTERNAL statement or a nested interface block for each dummy argument that is a dummy procedure, even though this may not be necessary in the procedure definition. REFERENCES: ISO/IEC 1539:1991 (E) Sections 12.2 and 12.3.2.1 EDIT(S): None. SUBMITTED BY: J.C.Shepherd, X3J3/92-016 HISTORY: Approved as X3J3/92-161 at meeting 122 by a vote of 24-0 -------------------------------------------------------------------------- NUMBER: 000064 TITLE: SPACING result for 0.0 KEYWORDS: SPACING intrinsic DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Is the SPACING intrinsic function intended to return absolute spacing of model numbers about 0.0 when its argument is 0.0? Section 13.12.100 under Result Value specifies that the result should be b**(e-p); this is not equal to the absolute spacing of model numbers around zero because zero has e == 0, so b**(e-p) provides a much larger value than expected. ANSWER: Yes. Discussion: Since the smallest magnitude model numbers are TINY(X) and -TINY(X), the absolute spacing around zero is TINY(X). It was intended that the "otherwise" clause of the SPACING definition apply to this case. REFERENCES: ISO/IEC 1539:1991 (E) Sections 12.7.1 and 13.13.100. EDIT(S): In section 13.13.100, after "Result Value." change "The" to "If X is not zero, the". In the same section, change "; otherwise " to ". Otherwise". SUBMITTED BY: J.K.Reid HISTORY: WG5/N786a item 234/7, N815a item 6 (X3J3/92-136 item 6) Approved as X3J3/92-171 at meeting 122 by a vote of 22-0 -------------------------------------------------------------------------- NUMBER: 000065 TITLE: Block and Nonblock DO Construct KEYWORDS: block DO construct, nonblock DO construct DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following DO loop: DO 10, I = 1, 10 K = I 10 CONTINUE It can be parsed using either of the following two paths: R816 is R817 is R818 is R819 is DO