From janshep@watson.ibm.com Fri Jan 19 10:20:48 1996 Received: from convex.convex.com by mozart.convex.com (8.6.4/1.28) id KAA27253; Fri, 19 Jan 1996 10:20:42 -0600 Received: from watson.ibm.com by convex.convex.com (8.6.4.2/1.35) id KAA26971; Fri, 19 Jan 1996 10:26:25 -0600 Message-Id: <199601191626.KAA26971@convex.convex.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6057; Fri, 19 Jan 96 11:25:19 EST Date: Fri, 19 Jan 96 11:25:18 EST From: "Janice C. Shepherd" To: lrr@cray.com, bleikamp@convex.convex.com, whitlock@tle.enet.dec.com, gra@epcfta.edinburgh.ac.uk Status: OR PC File: 96-006b.0 Archive: 96-006.B0 ############################################################################## # # # X3J3/96-006 # # # # Part B # # # # Interpretations approved by SC22/WG5 (status codes W, P) # # # ############################################################################## -------------------------------------------------------------------------------- NUMBER: 00000a TITLE: Minor edits and corrections for Technical Corrigendum #1 KEYWORDS: typographical errors DEFECT TYPE: Erratum STATUS: Published QUESTION: ANSWER: EDITS: 1. Introduction, Overview, Data Concepts, last sentence [xvi:1-2]; Delete the sentence "The section concludes ... names." 2. 2.4.6, third sentence [15:25]; Change "of" to "or". 3. 12.4.1.1, first paragraph, last line [172:41]; Change "of the the dummy" to "of the dummy" 4. 12.5.2.4, at end of first paragraph [177:29]; Add new sentence "When a statement function is invoked, an instance of that statement function is created." 5. 13.13.25, Result Value, Case (ii), at beginning of the third line [203:23]; Change "1,sh" to "sh,1". 6. 13.13.66, Result Value, Case (iii) [220:25]; Change",[" to "[" (i.e. delete comma). 7. Annex A, conformable [255:27]; Change "2.4.7" to "2.4.5". 8. Annex A, constant [255:38]; Change "2.4.4" to "2.4.3.1.2". 9. Annex A, derived type [256:23]; Change "2," to "2)". 10. Annex A, extent [257:8]; Change "2.4.7" to " 2.4.5". 11. Annex A, literal constant [258:19]; Change "2.4.4" to "2.4.3.1.2". 12. Annex A, main program [258:22]; Change "2," to "2)". 13. Annex A, module [258:25]; Change "4," to "4)". 14. Annex A, named constant [258:34]; Change "2.4.4" to "2.4.3.1.2". 15. Annex A, procedure [259:19]; Change "3," to "3)". 16. Annex A, rank [259:31]; Change "2.4.7" to "2.4.5". 17. Annex A, shape [ 260:12]; Change "2.4.7" to "2.4.5". 18. Annex A, size [260:14]; Change "2.4.7" to "2.4.5". 19. Annex A, subobject [260:35]; Change "2.4.3.2" to "2.4.3.1". 20. Annex A, target [261:9]; Change "specified in a" to "specified in a TARGET statement or". 21. Annex A, variable [261:30]; Change "2.4.5" to "2.4.3.1.1". HISTORY: The initial set of 20 items, all except item 3, prepared at WG5 (Victoria, BC) and submitted to X3J3 122, July 1992. Item 3 submitted at X3J3 meeting 123, November 1992. Approved in X3J3 letter ballots 92-182 and 930-016. N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 00000b TITLE: Minor edits and corrections for Technical Corrigendum #2 KEYWORDS: typographical errors DEFECT TYPE: Erratum STATUS: Published QUESTION: ANSWER: EDITS: 1. 11.3.3.7, in the second sentence [161:16], change "C.11.5" to "C.11.4" 2. Annex A, host association [257:29]; Change "11.2.2" to "12.1.2.2.1". 3. Annex C, first example [273:14]; change "ENDTYPE" to "END TYPE". 4. Page 250, section 14.7.5, item (8) change 'input/output IOSTAT= specifier' to 'IOSTAT= specifier' Reason: 'input/output' is redundant. [250:24] 5. Page 245, section 14.1.2.5, in the second sentence [245:3] change 'It' to 'Outside the type definition, it'. Reason: a component name appears in the derived type definition as well as possibly appearing in a component of a structure of that type. 6. In 13.13.42 IBITS, Result value, change '.... bit POS right-adjusted' to '.... bit POS, right-adjusted' [210:23] Rationale: it is the result, not POS, that is right-adjusted. 7. In 4.3.1 Numeric Types delete the last sentence "In this standard..." [27:2-3] Rationale: this is a not quite accurate restatement of R306 in section 3.2.3. ("unsigned" is not defined for boz numeric constants) 10. Page 339, section D.2.3 [339:3], add after the line for "'" ' " R408 R409 R410 R420' Rationale: Terminal symbol " was omitted from list 11. Section 7.2.3., first sentence [85:2] Change "operator" to "operation". 12. Section 10.9.1.2., first sentence [152:23] After " " add "(10.9)" 13. Annex A, [255:42] Change "CASE" to "SELECT CASE" 14. Section C4.3 [266:17] Change "KIND" to "kind". 15. Section C10 [281:5] Change "an apostrophe edit descriptor" to "a character constant edit descriptor delimited with apostrophes" 16. Section C10 [281:6-7] Change "the apostrophe edit descriptor" twice to "the edit descriptor" Rationale: for 15 and 16: In section 10 the term "apostrophe edit descriptor" is absent (see 10.2.1 and 10.7.1) 17. Section C13.1.6.3 [294:39-42] Delete word: "Declared" (4 times) Capitalize the first word after the deleted "Declared"s Rationale: In section 13 descriptions of these functions do not contain the word "declared". These array inquire functions allow certain properties of an array to be determined dynamically. HISTORY: m124 Submitted Feb 1993, papers 93-036, 93-078, 93-081 93-111 m125 X3J3 ballot approved items 1-3 94-034 m128 X3J3 ballot approved 4 (as part of 00000c, then moved here) 94-160 m129 WG5 ballot approved N984 m131 WG5 approved items 5-7 and items 10-17 (as part of 00000c, then moved here) -------------------------------------------------------------------------------- NUMBER: 00000c TITLE: Minor edits and corrections for Technical Corrigendum #3 KEYWORDS: typographical errors DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: ANSWER: EDITS: 18. In section 9.3.4.8 [117:27-28] change: 'READ specifies that the WRITE and ENDFILE statements must not refer to this connection.' to: 'READ specifies that the WRITE, PRINT, and ENDFILE statements must not refer to this connection.' Rationale: The same restriction applies to the PRINT statement. SUBMITTED BY: HISTORY: 93-289 m127 submitted items 4-5 94-034 m128 X3J3 ballot item 4 approved (moved to 00000b), 5 failed 94-028 m128 additional items 6-7 94-028r1 m128 approval of items 6-7 uc 94-084 m128 correction of item 5, approved uc 94-116 m129 X3J3 ballot items 5,6,7 approved 21-2 94-165 m129 submitted item 10, approved u.c. 94-161r2 m129 submitted items 11-17, approved u.c. 94-221 m130 X3J3 ballot approved 22-1 with edit to item 17 N984 m131 WG5 approved items 5-7 and items 10-17, moved to b 94-323 m131 submitted item 18, approved u.c. 95-034r1 m132 X3J3 ballot item 18, approved, 20-0, with edits 95-281 m135 WG5 ballot approved item 18 -------------------------------------------------------------------------------- NUMBER: 000001 TITLE: Optimization of Fortran programs KEYWORDS: expression - arithmetic, mathematical equivalence, numeric operations, optimization DEFECT TYPE: Interpretation STATUS: Published QUESTION: Given a fragment such as 10 SUM = A + B 20 D = SUM + C does the standard allow the processor the freedom to replace this two statement fragment with any of the following single statements: 100 D = (A + B) + C 110 D = A + (B + C) 120 D = (A + C) + B 130 D = (B + A) + C 140 D = C + (B + A) ANSWER: The Fortran standard grants to processors an unlimited freedom to reorganize and modify programs, provided only that the execution "fulfills the interpretations herein" (1.4). In sections 7.1.7.1, 7.1.7.3, and elsewhere, specific additional freedoms are granted processors in expression evaluation. Generally speaking, all of these freedoms support what is called "optimization", the altering of the program in some way that is thought to improve a specific property, often performance, of the program. In this particular case SUM, in statement 20, is not an expression, but a reference to the result of a previous assignment. The additional freedoms granted for expression evaluation do not apply. Thus only those processors that can make the replacement and still "fulfill the interpretations herein" are permitted to do so. For these processors the answer is yes, for all other processors the answer is no. The "interpretation herein" is that SUM is a primary (7.1.1.1) of the expression "SUM + C" and the reference to SUM requires its value (Section 6, first paragraph). The determination of SUM's value was specified by assignment statement 10. The result of that assignment, with its possible conversions of "A + B" to the type and type parameters of SUM, is the value of SUM. This is the interpretation that must be fulfilled by conforming processors. A common optimization for this fragment is to replace it by statements such as 100, 130, etc. where the calculation of A + B appears in parenthesis. This replacement corresponds to the calculation of A + B in a temporary location (i.e., a register) and then accessing that temporary location instead of storing the result in SUM and then accessing that stored value. EDITS: None. SUBMITTED BY: J. C. Adams 119-JCA-2 (119.002) HISTORY: 119-RL-1 (119.047) 92-044 S20.120A 92-104 Interpretation 92-147 m122 approved by a vote of 21-1 92-267r m123 Edit approved Comments Accompanying Ballots on N865, Munchhausen, Rolison and Shen N881 WG5 approved. However ballot comments led X3J3 to reconsider 93-132 m125 approved 18-4 93-255r1 m127 ballot failed 23-1 94-026r1 m128 proposed response (using 'freedom') 94-025r1 m128 proposed response (using 'freedoms') approved 17-2 94-116 m129 X3J3 ballot approved 22-1 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000002 TITLE: Default main program name KEYWORDS: main program, PROGRAM statement DEFECT TYPE: Interpretation STATUS: Published QUESTION: Some implementations of Fortran 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 name, would it be standard conforming? Would the processor in the example above be standard conforming if it used $MAIN, for example, instead of MAIN? ANSWER: This situation is covered by the third paragraph of sections 1.4 and C.11.1 of ISO/IEC 1539:1991. Specifically, section 1.4, item (1), of ISO/IEC 1539:1991 states: A processor conforms to this International Standard if: (1) It executes any standard-conforming program in a manner that fulfills the interpretations herein, subject to any limits that the processor may impose on the size and complexity of the program. If, as in the example provided, the processor supplies a PROGRAM statement with a symbolic name that 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. REFERENCES: ISO/IEC 1539:1991 (E) sections 1.4 and C.11.1 ANSI X3.9-1978 section 1.4 (page 1-2, lines 25-27) EDITS: 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) m123 X3J3 draft response at meetings 120, 123 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000003 TITLE: Preconnected units and UNIT=* KEYWORDS: i/o preconnected units, i/o unit, i/o UNIT=* DEFECT TYPE: Interpretation STATUS: Published 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 sections 9.3and 9.4.4.2 of ISO/IEC 1539:1991. These sections state 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. REFERENCES: ISO/IEC 1539:1991 (E) sections 9.3 and 9.4.4.2 ANSI X3.9-1978 section 12.9.2 EDITS: None. SUBMITTED BY: A.D. Tait, 118-ADT-2 (118.024) HISTORY: 119-ADT-2 (119.013) m123 Approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000004 TITLE: Blanks in format specifications in free form source KEYWORDS: source form - free, i/o format specification, blanks DEFECT TYPE: Erratum STATUS: Published QUESTION: Is the following format specification valid in free form source? FORMAT (B N) ANSWER: Yes. Discussion: Sections of Fortran 90 are not consistent. 3.3.1: In free form, blank characters must not appear within lexical tokens other than in a character context. and A blank must be used to separate names, constants, or labels from adjacent keywords, names, constants, ... 10.1.1: Additional blank characters may appear at any point within the format specification, with no effect on the interpretation of the format specification, except within a character string edit descriptor (10.7.1, 10.7.2). It can be seen that the text in chapter 3 does not consider edit descriptors. The text will be revised so that: -- blanks are allowed in edit descriptors. These changes are desirable because format specifications are conceptually their own sub-language, where the components thereof are not affected by the source form of the containing procedure and are not subject to most other syntactic rules. Thus, the rules concerning blanks in keywords do not apply to edit descriptors in format specifications. This treatment of format specifications is desirable so that "run-time formats" can be processed independently of the source form of the procedure containing a data transfer statement. EDIT: Section 3.3.1, second paragraph [22:6], change "... character context." to "... character context or in a format specification." SUBMITTED BY: J. T. Martin 119-JTM-2 (119.015) HISTORY: 119-JTM-2 119-RPK-1 92-044 S20.120, number 4 92-075 92-145 Draft Interpretation by CIO, withdrawn 92-176 m122 by approved uc 92-326 ballot comments (jw note) m124 minutes, approved 15-2 93-111 m125 ballot approved; accept Martin edits 94-160 m129 WG5 ballot, failed 94-174r2 m129 elaborated discussion, removed first and second edit; approved 21-0 94-221 m130 X3J3 ballot approved 21-2, accept Shepherd edits N984 m131 last paragraph of discussion deleted WG5 approved -------------------------------------------------------------------------------- NUMBER: 000005 TITLE: Namelist output of zero length character strings KEYWORDS: i/o namelist output, zero length DEFECT TYPE: Interpretation STATUS: Published 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. EDITS: None. SUBMITTED BY: J. T. Martin, 119-JTM-3 (119.016) HISTORY: 119-RPK-2 (119.064), & 119-JTM-6 (119.041) Approved in ballot 92-182 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000006 TITLE: Procedure specifications in a scoping unit KEYWORDS: procedure specification, interface body DEFECT TYPE: Erratum STATUS: Published 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. A module procedure definition and the appearance of the procedure name in a type statement c. A module procedure definition and an interface body for the procedure d. An interface body for the procedure and the appearance of the procedure name in an EXTERNAL statement 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 implies 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. EDIT: At the end of the fourth paragraph following R1207 in 12.3.2.2 [170:42], 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: X3J3/92-170 m122 Approved uc 92-312 m123 Revised following letter ballot, approved uc N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000007 TITLE: Duplicate module procedures in interface blocks KEYWORDS: module procedure name, interface block, generic name, MODULE PROCEDURE statement DEFECT TYPE: Erratum STATUS: Published QUESTION: See, also, item 000008 which this item subsumes. 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? Section 12.3.2.1 indicates: "A procedure must not have more than one explicit specific interface in a given scoping unit." 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. A MODULE PROCEDURE statement does not specify the explicit interfaces of the module procedure names, so the text referenced from 12.3.2.1 does not apply. Example: INTERFACE INT_1 MODULE PROCEDURE FOO, FOO ! second FOO is illegal MODULE PROCEDURE FOO1 MODULE PROCEDURE FOO1 ! FOO1 is illegal here END INTERFACE INTERFACE INT_2 MODULE PROCEDURE FOO2A, FOO2B END INTERFACE INTERFACE INT_2 MODULE PROCEDURE FOO2B, FOO2C ! FOO2B is illegal here END INTERFACE EDIT: The following additional constraint should be added to section 12.3.2.1 [167:36]: Constraint: A in a must not be one which previously had been specified in any with the same generic identifier in the same specification part. SUBMITTED BY: S. M. Lammers, 119-SML-1 (119.019) HISTORY: 120-MBSH-4A (120.096A) Original interpretation 92-039 Adopted because this interpretation is more consistent with requirements concerning duplication of other specification statements in a given scoping unit. 92-095 modification WG5/N786A Commented on, Victoria meeting, item marked 1167/36+. 92-155A m122 approved uc 94-034 m128 X3J3 ballot failed 25-3 94-093 m128 alternate answer proposed, approved uc 94-116 m129 X3J3 ballot failed 15-8 94-197r1 m129 revised discussion and edit, approved 15-1 94-221 m130 X3J3 ballot approved 23-0, accept Shepherd edit N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000008 TITLE: subsumed by 000007: Module Procedure Name in Multiple Interface Blocks KEYWORDS: DEFECT TYPE: STATUS: Subsumed 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: REFERENCES: 120-MBSH-4A (120.096A) EDITS: SUBMITTED BY: S. M. Lammers HISTORY: 119-SML-1 (119.019) item 5, question 4 92-039 Interpretation questioned 92-155A approved by uc as the response to NUMBER 000007 subsumed by 000007 -------------------------------------------------------------------------------- NUMBER: 000009 TITLE: Generic interfaces with the same name in a program KEYWORDS: generic interface, interface - generic, use association DEFECT TYPE: Interpretation STATUS: Published 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. EDITS: None. SUBMITTED BY: Larry Rolison, 120-LRR-4 (120.029), question 1 HISTORY: 120-MBSH-1A (120.084A) m120 proposed X3J3/92-040 (121-JKR-8) Questioned in X3J3/92-099 Approved X3J3/92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000010 TITLE: Generic interfaces with the same name in a scoping unit KEYWORDS: generic interface, interface - generic DEFECT TYPE: Interpretation STATUS: Published QUESTION: Are two generic interfaces with the same name allowed in the same scoping unit? 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. EDITS: None. SUBMITTED BY: Larry Rolison, 120-LRR-4 (120.029), question 2 HISTORY: 120-MBSH-1A (120.084A) m120 Proposed X3J3/92-040 (121-JKR-8) Questioned in X3J3/92-100 Approved as X3J3/92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000011 TITLE: Multiple accessible defined operator and assignment interfaces KEYWORDS: interface block, defined assignment, defined operator DEFECT TYPE: Interpretation STATUS: Published QUESTION: Consider the following excerpts from section 14.1.2 [241]: Excerpt (a): Within a scoping unit, entities in the following classes: (1) Named variables that are not statement entities (14.1.3),..., generic identifiers, derived types, and namelist group names ... are local entities of that scoping unit. Excerpt (b): Within a scoping unit, a name that identifies a local entity of one class must not be used to identify another local entity of the same class, except in the case of generic names (12.3.2.1). A name that identifies a local entity of one class may be used to identify a local entity of another class. The standard defines both the terms "generic identifier" and "generic name" in section 12.3.2.1 [168]. "Generic identifier" is defined to encompass the three concepts of a generic name, a defined operator, or an equals symbol on a generic specification. "Generic name" refers to the BNF term for the name that may appear on an interface specification. The text from section 14 cited in (a) uses the term "Generic identifier" but the text cited in (b) uses the term "generic name". Is the intent behind the choice of different words in section 14 to prohibit a program from containing multiple interface blocks for the same operator and multiple accessible defined assignment interfaces? ANSWER: No. Discussion: Section 11.3.2 states: "If two or more generic interfaces that are accessible in a scoping unit have the same name, the same operator, or are both assignments, they are interpreted as a single generic interface" Thus, two or more interfaces that have the same name, the same operator, or are assignment interfaces are not only permitted but the interfaces are considered to be a single generic interface. The text cited in (b) above was specifically discussing "names" and hence "generic names" were singled out. The text cited in (a) above was discussing all entities that are local to a scoping unit, not just named entities. EDITS: None. SUBMITTED BY: Larry Rolison, 120-LRR-4 (120.029), question 3 HISTORY: 120-MBSH-1A (120.084A) Originally passed as m123 Revised in response to ballot comments but no vote taken - withheld for further consideration 93-029 Slight rewording for clarification m124 Approved unanimous consent 93-111 m125 X3J3 ballot approved with Rolison edits 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000012 TITLE: Type of a named constant when there is implicit mapping KEYWORDS: named constant, PARAMETER statement, implicit mapping DEFECT TYPE: Erratum STATUS: Published QUESTION: See, also, item 000023 which this item subsumes. See, also, item 000114 which this item subsumes. See, also, item 000134 which this item subsumes. Section 5.2.10 states: "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." Question 1: It is not clear what is meant by the phrase "the implicit typing rules currently in effect" Note that this phrase also appears in sections 7.1.6.2 and 5.4. Does this mean that more one implicit mapping can exist in a scoping unit? Are the following code fragments valid Fortran 90? Example 1. PARAMETER (A=1) IMPLICIT INTEGER (A) Example 2. PROGRAM MAIN IMPLICIT INTEGER (Z) ! Z is mapped to type integer ... CONTAINS SUBROUTINE INNER PARAMETER (ZERO = (0.0, 0.0)) ! Name starts with Z IMPLICIT COMPLEX (Z) ! Z is mapped to type complex ... END SUBROUTINE END PROGRAM Question 2: The statement in section 5.2.10 seems inconsistent in that the program unit SUBROUTINE SUB ( ) REAL, DIMENSION (2) :: R PARAMETER (R = 1) END appears to be valid, while the program unit SUBROUTINE SUB ( ) DIMENSION R(2) PARAMETER (R = 1) END does not appear valid. Was it intended that one case be valid while the other is not? ANSWER: Answer 1: No in both cases. In each scoping unit there is a single mapping. The code fragments are not valid. Answer 2: No, that was not the intent; both program units are valid. Discussion: Section 5.3 (IMPLICIT statement) states: In each scoping unit, there is a mapping, which may be null, between each of the letters A,B, ...Z and a type (and type parameters). The reference to the singular "a mapping" is intended to convey that in each scoping unit there is a single mapping. Unfortunately the phrase "the implicit typing rules currently in effect" may give the impression that more than one mapping can exist. This is an error which is corrected by the edits specified below. Section 5.2 states: The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification. Section C.5.1 also supports this intent. Thus there is evidence in the standard that the same restrictions should be applied to objects independent of whether their attributes were specified in a type declaration statement or an attribute specification statement. An edit below clarifies this intent. EDITS: 1. In section 5.2.10 change the second paragraph to: [53:43-47] "The named constant must have its type, type parameters, and shape specified in a prior specification of the or declared implicitly (5.3). If the named constant is typed by the implicit typing rules, its appearance in any subsequent specification of the must confirm this implied type and the values of any implied type parameters." 2. In section 5.3 in line 3 of the paragraph that starts with "Any data entity that is" after 'not null.' and before the Corrigendum 1 addition [54:35], add: "The mapping for the first letter of the data entity must either have been established by a prior IMPLICIT statement or be the default mapping for the letter." 3. In section 5.4 in the penultimate paragraph [56:22-24]: in line 3, delete "currently" and in lines 4-5 replace "this implied type" by "the implied type and type parameters". 4. In section 7.1.6.2, in line 2 of the paragraph after the constraint [79:23] delete "currently". SUBMITTED BY: (Question 1) J. T. Martin, 120-JTM-9 (120.046), question 3 (Question 2) Jon Steidel, 120-JLS-2 (120.020) case 3 HISTORY: 120-LJM-5 (120-093) 92-172 m122 modified, passed 12 subsumes 23 following letter ballot 93-73r2 m124 adopted uc 93-111 m125 ballot approved with Rolison edits 93-150 m125 edits 93-227r1 m126 revised to make 12, 114 and 134 consistent, edit added, approved uc 93-255r1 m127 ballot failed 19-5 m127 12 subsumes 114, 134 93-328 m127 response 94-050 m128 revised edits, approved uc 94-116 m129 X3J3 ballot approved 22-1 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000013 TITLE: Implicit mapping of an interface block KEYWORDS: implicit mapping, interface block DEFECT TYPE: Amendment STATUS: Published QUESTION: Is the implicit mapping 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 EDITS: 1. In Section 5.3 in the second paragraph after the constraints [54:30], 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 [55:2] 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 [55:3], change "INTEGER FUN, I" to be "INTEGER FUN". SUBMITTED BY: Larry Rolison 120-LRR-3 (120.028) LAST SIGNIFICANT CHANGE: 93-07-09 000013 approved, WG5 N930 resolution B2 HISTORY: X3J3/92-102A Draft response WG5 N786A Victoria, questioned in X3J3/92-154A m122 Revised edit approved 21-1. X3J3/92-267r m123 Edit approved WG5 N881 ballot failed WG5 N930 Berchtesgaden, resolution B2 approved -------------------------------------------------------------------------------- NUMBER: 000014 TITLE: Interface for a character function with a variable length result KEYWORDS: character function, variable length, interface - explicit, function result DEFECT TYPE: Interpretation STATUS: Published 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. EDITS: None. SUBMITTED BY: Larry Rolison, 119-LRR-1, part II HISTORY: 119-KWH-3A (119-70A) Approved in ballot 92-182 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000015 TITLE: Error in fourth constraint for R429 KEYWORDS: derived type definition DEFECT TYPE: Erratum STATUS: Published 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. The length specified in a character should be similarly restricted. REFERENCES: ISO/IEC 1539:1991 (E) sections 4.4.1, 5.1, 5.1.1.5, & 7.1.6.2 EDIT: Replace the fourth constraint after R429 [33:36] with: 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) m123 Approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000016 TITLE: Character length specification KEYWORDS: character length specification, derived type definition DEFECT TYPE: Erratum STATUS: Published 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: Replace the text following the constraints for R508 [42:29] with: The in a CHARACTER and the * in an or in a of a type definition specify character length. The * in an or a specifies an individual length and overrides the length specified in the , if any. If a * is not specified in an or a , 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) 92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000017 TITLE: Creation of entities by local names in rename-list KEYWORDS: local name, use renaming DEFECT TYPE: Interpretation STATUS: Published QUESTION: Does a local-name on a rename-list create a new data-entity? For example, is the local name Q a new data entity or is Q a rename of the entity P in the following example? MODULE UTIL PUBLIC P CONTAINS SUBROUTINE P END END MODULE UTIL MODULE MID1 USE UTIL, Q=>P ! Is Q a new data entity or 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 ! Is this legal? Does it refer to P? END SUBROUTINE ENDUSER ANSWER: Multiple renames of the same do not constitute separate entities. Subsequent appearances of the refer to the single entity. In the example, Q does not create a new entity. Thus "CALL Q" in the subroutine is legal. Discussion: In section 11.3.2 [158:15-16], the standard states that a local name in the rename list is a "local name for the entity" which is intended to mean that a new entity is not created. EDITS: None. SUBMITTED BY: E. A. Johnson, 119-EAJ-1 (119.057) HISTORY: 120-LF-1 (120.089) 077, ui 18 (jw note) 92-296 m123 Response proposed, approved by unanimous consent N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000018 TITLE: Valid characters for indicating fixed form statement continuation KEYWORDS: source form - fixed - statement continuation, character set DEFECT TYPE: Interpretation STATUS: Published QUESTION: Line 3 of the first paragraph of 3.3.2.3 states: If character position 6 contains any character other than blank or zero, character positions 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. EDITS: None. SUBMITTED BY: J. C. Adams, 120-JCA-13 (120.013) HISTORY: 120-RL-1 (120.058) Originally proposed X3J3/92-105 m121 Approved 20-0 X3J3/92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000019 TITLE: Correctness of last example in section 4.5 KEYWORDS: array constructor DEFECT TYPE: Interpretation STATUS: Published 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: 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. EDITS: None. SUBMITTED BY: J. C. Adams, 120-JCA-14 (120.014) HISTORY: 120-JTM-10 (120.057) m123 Approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000020 TITLE: References to the same derived type by different names KEYWORDS: derived type reference, derived type definition DEFECT TYPE: Interpretation STATUS: Published 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 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 agrees in all these respects 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. EDITS: None. SUBMITTED BY: J. C. Adams, 120-JCA-15 (120.015), 120-JLS-5 (120.023) HISTORY: 120-KWH-1 (120.078) 92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000021 TITLE: References to different derived types with the same name KEYWORDS: derived type definition, derived type reference DEFECT TYPE: Interpretation STATUS: Published 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 defined in 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 EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-1 (120.019) HISTORY: 120-KWH-2A (120.083A) Originally answered X3J3/92-037 (121-JKR-5) Modification requested X3J3/92-049 (121-ADT-9) p7 Discussed in X3J3/92-050 (121-ADT-10) p4 Discussed in X3J3/92-080 m121 Approved 20-0 X3J3/92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000022 TITLE: Use of derived type name in host scoping unit KEYWORDS: derived type, host association DEFECT TYPE: Interpretation STATUS: Published 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 states 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 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 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 EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-2 (120.020) cases 1 and 2 HISTORY: 120-RPK-1A (120.092A) Proposed X3J3/92-038 (121-JKR-6) Questioned by X3J3/92-097 m121 Approved 20-0 X3J3/92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000023 TITLE: subsumed by 000012: Type of a Named Constant in an Internal Procedure KEYWORDS: DEFECT TYPE: STATUS: Subsumed 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: EDITS: SUBMITTED BY: Jon 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 item 000012 subsumed by 000012 -------------------------------------------------------------------------------- NUMBER: 000024 TITLE: IMPLICIT NONE and the type of a function result KEYWORDS: IMPLICIT NONE, internal procedure, function result DEFECT TYPE: Interpretation STATUS: Published QUESTION: An internal function 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. EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-2 (120.020) case 4 HISTORY: 120-RPK-3A (120-094A) 92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000025 TITLE: Resolution of internal procedure references KEYWORDS: host association, internal procedure, IMPLICIT NONE, procedure references DEFECT TYPE: Interpretation STATUS: Published 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 EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-2 (120.020) case 5 HISTORY: 120-RPK-4 (120-095)m120 Proposed X3J3/92-050 (121-ADT-10) page 4, Questioned X3J3 m121 draft response X3J3/92-182 Approved in ballot N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000026 TITLE: Bounds of array expressions KEYWORDS: array bounds, array expression, expression - array DEFECT TYPE: Interpretation STATUS: Published QUESTION: Is it the intent of the standard 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? That is, given: REAL,TARGET,DIMENSION(5:10) :: A REAL,DIMENSION(:),POINTER :: P P => A(5:10) PRINT *, LBOUND (P) Does the PRINT statement result in the value 1 being written? Previous versions of the draft standard stated that the lower bounds of array expressions were 1. Where are those words in the standard? Reading chapter 7 indicates that an expression may be 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) F F T (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 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 (c) is described in section 5.1.2.4.2. 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). 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 EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-3 (120.021) HISTORY: 120-LJM-4A (120.088A) ballot comments, 216, 329 (jw note) m123 Approved N881 WG5 approval ------------------------------------------------------------------------------- NUMBER: 000027 TITLE: Requirements for pointer and target association KEYWORDS: POINTER attribute, TARGET attribute, pointer association DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: If PTR has the POINTER attribute and TGT has the TARGET or POINTER attribute, under which of the following other conditions are PTR and TGT considered to be pointer associated, i.e., under which of the following conditions does ASSOCIATED(PTR, TGT) return a value of .TRUE.: a) PTR and TGT have different types? b) PTR and TGT have different type parameters? c) PTR and TGT have different ranks? d) PTR and TGT have different sizes? e) PTR and TGT have different shapes? f) PTR and TGT have different bounds? g) PTR and TGT refer to the same set of array elements/storage units, but not in the same array element order? h) PTR and TGT have array elements/storage units whose range of memory addresses overlap, but they have no identical array elements/storage units? i) PTR and TGT have at least one but not all identical array elements/storage units and all the identical elements have the same subscript order value in both PTR and TGT? j) PTR and TGT have at least one but not all identical array elements/storage units but not all the identical elements have the same sub script order value in both PTR and TGT? ANSWER: The conditions d), e), g), h), i) and j) are sufficient for ASSOCIATED (PTR, TGT) to return a value of .FALSE.. The conditions a), b), c) and d) are such that if any are true, ASSOCIATED (PTR, TGT) is an invalid reference. In determining whether a pointer and a target are associated, the bounds are relevant only for determining which elements are referenced. The extents of each dimension of PTR and TGT must be the same, thus their shapes must match which is covered by condition (e). If TGT is zero sized, ASSOCIATED (PTR, TGT) returns .FALSE.. Discussion: It is the intent of the standard that the two argument form of the ASSOCIATED intrinsic function returns true only if the association of POINTER and TARGET is as if the pointer assignment statement POINTER => TARGET was the last statement executed prior to the execution of the statement invoking the ASSOCIATED function. This is not clear in the definition of the ASSOCIATED intrinsic or elsewhere in the standard. Clarifying edits are provided. EDITS: 1. In section 13.13.13 [198:31] in the description of the TARGET dummy argument add ", and have the same type, type parameters, and rank as POINTER" following "must be a pointer or target" 2. In section 13.13.13 replace Case (ii) with [198:37-38] "Case (ii): If TARGET is present and is a scalar target, the result is true if TARGET is not a zero-sized storage sequence and the target associated with POINTER occupies the same storage units as TARGET. Otherwise the result is false. If POINTER is disassociated, the result is false." 3. In section 13.13.13 replace Case (iii) [199:1-3] with "Case (iii): If TARGET is present and is an array target, the result is true if the target associated with POINTER and TARGET have the same shape, are neither of size zero nor arrays whose elements are zero-sized storage sequences, and occupy the same storage units in array element order. Otherwise the result is false. If POINTER is disassociated, the result is false. Case (iv): If TARGET is present and is a scalar pointer, the result is true if the target associated with POINTER and the target associated with TARGET are not zero-sized storage sequences and they occupy the same storage units Otherwise the result is false. If either POINTER or TARGET is disassociated, the result is false. Case (v): If TARGET is present and is an array pointer, the result is true if the target associated with POINTER and the target associated with TARGET have the same shape, are neither of size zero nor arrays whose elements are zero-sized storage sequences, and occupy the same storage units in array element order. Otherwise the result is false. If either POINTER or TARGET is disassociated, the result is false." SUBMITTED BY: Jon Steidel, 120-JLS-4 (120.022) HISTORY: 120-LJM-3A (120.081A) m121 Original response proposed 92-061 (121-ADT-9) p9 & X3J3/92-061 Questioned response (121-ADT-13) item 27 92-093A m121 Approved 92-329 (jw note) m123 Approval rescinded at m123 (uc) 93-099r1 m124 Revised response adopted (15-2) 93-111 m125 ballot failed, returned to subgroup 93-135r m125 Based on comments returned with the X3J3 letter ballot following m124, the revised response was prepared and adopted 15-3. 93-255r1 m127 ballot failed 17-7 94-289 m130 revised answer, approved u.c. 94-306 m131 X3J3 ballot failed 16-3 95-281 m135 revised response, added edits, WG5 approved 96- m136 X3J3 ballot approved 15-1, retains WG5 approval ------------------------------------------------------------------------------- NUMBER: 000028 TITLE: Host association and Implicit type rules KEYWORDS: use association, host association, implicit typing DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION 1: Consider the following program fragment: MODULE A CONTAINS SUBROUTINE B(Z) IMPLICIT INTEGER (X) 10 Z = XXX !Local variable or invalid function reference? ... END SUBROUTINE REAL FUNCTION XXX() ... END FUNCTION END MODULE In the above example in statement 10, is XXX an implicitly typed scalar variable or an erroneous function reference to module procedure XXX? That is to say, does the syntax of the reference determine which entity is referenced? QUESTION 2: Consider the following program fragment: MODULE X INTEGER, DIMENSION(10) :: A ... CONTAINS SUBROUTINE Y() ... CONTAINS SUBROUTINE Z(I) 20 A(I) = I ! Host associated array reference ! or invalid reference to function A? END SUBROUTINE FUNCTION A(K) ! Hides array A in module spec part? ... END FUNCTION END SUBROUTINE END MODULE Is the reference to A in statement 20 a reference to the array A declared in the module specification or an invalid reference to the internal procedure A? ANSWER 1: The reference to XXX is an invalid reference to the host associated module procedure XXX. The syntax of the reference does not determine which entity is referenced. ANSWER 2: The reference to A is an invalid reference to the host associated internal procedure A. Discussion: Section 5.3, in the fourth paragraph beginning "Any data entity ...", defines which data entities are implicitly typed. This definition excludes variables made accessible by use association or host association. In the first example, a form of reference does not differentiate between a host associated entity and a local implicitly typed scalar. In the second example, within subroutine Y the definition of the internal procedure A makes the array A inaccessible by host association (section 12.1.2.2.1). The internal procedure A is accessible within subroutine Z by host association. The reference to A(I) in subroutine Z is an invalid reference to function A. EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-6 (120.024)) HISTORY: 120-RL-3 (120.060) ui 105 ballot comments (jw note) 93-134 m125 unanimous consent 93-255r1 m127 ballot failed 23-1 93-329 m127 approved uc 94-034 m128 X3J3 ballot failed 26-2 94-106r1 m128 revised response, approved u.c 94-116 m129 X3J3 ballot failed 16-7 94-164 m129 clarify question and answer, approved u.c. 94-221 m130 X3J3 ballot approved 23-0 95-044 m132 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000029 TITLE: Class of a defined operator KEYWORDS: defined operator, generic identifier, local entities - classes of DEFECT TYPE: Interpretation STATUS: Published 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: The word 'name' is used in a technical way throughout the standard. It is defined by R304 on page 19 and is not used in the definition of by R311, R704, R724 on page 21. A defined operator is a generic identifier (see page 168, lines 12 and 11 from the bottom), but it does not have a name. Therefore the rule in 14.1.2 does not apply. This is analogous to the situation for intrinsic operators, where it is permissible to have local variables named AND, OR, etc. REFERENCES: ISO/IEC 1539:1991 (E) sections 3.2.2, 3.2.4, 12.3.2.1, 14.1.2 EDIT: None. SUBMITTED BY: Jon 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) 92-106 Interpretation based on 121-JKR-2 92-148A m122 Approved by unanimous consent 92-252 m124 Approved by unanimous consent 93-111 m125 ballot approved with Weaver edit 94-160 m129 WG5 approved with Rolison edit 94-169 m129 Rolison edit N981 m131 WG5 approved ------------------------------------------------------------------------------- NUMBER: 000030 TITLE: Length of character literals in array constructors KEYWORDS: array constructor, character DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Consider the following example: CHARACTER :: NAMES (3) * 20 NAMES = (/ 'TOM', 'DICK', 'HARRY' /) This appears to be invalid due to a constraint in section 4.5, "Construction of array values": "Constraint: Each expression in the must have the same type and type parameters." The length of the string is a type parameter. Thus the array constructor sample above is invalid because the strings have different lengths. Consider another example: CALL SUB ( (/ 'TOM', 'DICK', 'HARRY' /) ) ... SUBROUTINE SUB (NAMES) CHARACTER :: NAMES(:) * (*) WRITE(*,*) LEN(NAMES) ... This also appears invalid. Question 1. Must each character string literal constant in an array constructor be the same length? Question 2. If the answer to 1 is "No", what values are printed by the second example? Question 3. If the answer to 1 is "Yes", another question arises. The syntax of an array constructor is described in section 4.5. In rule R432, is defined to be an or an . Since an may be an expression, a substring is a valid . Therefore each substring in an array constructor must have the same length and that length must be the same as the length of every other in the constructor. But a substring can contain nonconstant expressions as the starting point and ending point, or the starting point and ending point can be omitted (signaling the use of a default value). Since a substring can contain nonconstant starting and ending points, the constraint cited above cannot be detected at compile time and thus cannot be a constraint. Should this restriction be rephrased as prose in the text of the standard? ANSWER: The answer to question 1 is yes. Each character literal constant in an must be the same length. Both examples are nonstandard conforming. The answer to question 3 is yes. The following edits move the equal-length requirement from a constraint to prose in the text. Discussion: The awkwardness resulting from the requirement that each be the same length was noted by X3J3, but the committee could not reach agreement on an acceptable way to allow character literal constants of differing lengths in an . Since the length cannot always be determined at compile time, that part of the constraint must be changed to prose. EDITS: 1. In the second constraint following R435 [38:3-4] change: "the same type and type parameters." to: "the same type and kind type parameter." 2. Add the following paragraph after the constraints in 4.5. [38:4] If the expressions are of type character, each expression in the must have the same length type parameter. SUBMITTED BY: (Questions 1 and 2) Larry Rolison in 120-LRR-1 (120.026) (Question 3) Larry Rolison in X3J3/93-070 HISTORY: 120-LJO-1 (120.074) Response to Questions 1 and 2 - 93-070 m124 Question 3. submitted as 93-100 m124 proposed response, adopted by unanimous consent 93-111 m125 ballot approved with Rolison edit 94-160 m129 WG5 ballot, failed; 94-179 m129 minor edit changes 94-225r1 m130 adjust EDITS, as per WG5 ballot, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000031 TITLE: Overloaded implied-DO variable names KEYWORD: implied-Do variable, DATA statement DEFECT TYPE: Erratum STATUS: Published 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 includes the DATA statement or array constructor and this type must be integer. Is the following in error since J has type character and therefore does not have type integer? CHARACTER J INTEGER A(10) DATA (A(J), J=1,10) /10*5/ Is the following valid because, although J is a named constant, it has type integer? INTEGER J PARAMETER (J=5) INTEGER A(10) DATA (A(J), J=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(J), J=1,10) /10*5/ The EXTERNAL statement declares J to be a global name. If 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 in section 18.2.7 of X3.9-1978? Question 2: Are the conclusions and interpretations above correct or incorrect? If incorrect, for what specific reasons are they incorrect? Question 3: Are the examples 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 the same? If they are not exactly the same, provide examples which illustrate the differences. ANSWER: It was intended that the rules for implied-DO variables be similar to those in X3.9-1978. An edit to section 14.1.3 of ISO/IEC 1539:1991 clarifies these rules. The answers to the specific questions are: 1. Fortran 90 extended the rules for implied-DO variables in DATA statements in two ways: a) The type of an implied-DO variable must be integer but need not be default integer. b) FORTRAN 77 allowed the name of the statement entity also to be the name of a (scalar) variable or COMMON block (X3.9-1978, section 18.2.7) in (i.e. appearing in) the program unit containing the DATA statement or statement function statement. Fortran 90 allows the name of the statement entity also to be the name of a scalar variable or COMMON block appearing in or accessible from the enclosing scope (section 14.1.3 of ISO/IEC 1539-1991, with the changes in the EDITS section, below). 2. The detailing of the conclusions and justifications given below in (3) answer this. 3. The first example is in error because J is of type character and R537 requires integer type. The second example is in error. J is of type integer as required by R537, but the edit to section 14.1.3 prohibits the name of a statement entity also being the name of a constant in the same scoping unit. The third example is in error. The edit to section 14.1.3 prohibits the name of a statement entity also being the name of a derived type. The fourth example is in error. The edit to section 14.1.3 prohibits the name of a statement entity also being the name of an external function or subroutine. 4. The rules for implied-DO variables in DATA statements and in array constructors, with respect to typing and scope, are the same. REFERENCES: ISO/IEC 1539:1991, sections 5.2.9, 6.2.1, 14.1.2, 14.1.3. X3.9-1978, section 18.2.7 EDIT: Replace the last paragraph of section 14.1.3 with the following two paragraphs: [245:23] Except for a common block name or a scalar variable name, a name that identifies a global entity or local entity of class 1 (14.1.2) accessible in the scoping unit of a statement must not be the name of a statement entity of that statement. Within the scope of a statement entity, another statement entity must not have the same name. If the name of a global or local entity accessible in the scoping unit of a statement is the same as the name of a statement entity in that statement, the name is interpreted within the scope of the statement entity as that of the statement entity. Elsewhere in the scoping unit, including parts of the statement outside the scope of the statement entity, the name is interpreted as that of the global or local entity. SUBMITTED BY: Larry Rolison, 120-LRR-2 (120.027) LAST SIGNIFICANT CHANGE: 92-11-13 000031 new response HISTORY: ul 11, ul 26, ul 65, ul 117 (jw note) 92.049 p.11ff Griffiths' complaint 92.069a (120-RRR-1A) -- 1st response - all prohibited 92.112 -- 2nd response -- all allowed 92.132, #4, 5, 32, 33, 38, 39, 49 Email discussion 92.136, N815-7 WG5 suggests F77 restrictions 92.167a -- 3rd response drafted by DATA subgroup at m122; final action deferred due to 2 week rule Improved edits suggested by Janice Shepherd (private communication) 92-229b m123 -- 4th response approved (22-1) N865 ballot comments - edit to answer N881 WG5 approval 93-150 edits from WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000032 TITLE: Implicit declaration of a derived type KEYWORDS: derived type, IMPLICIT statement DEFECT TYPE: Erratum STATUS: Published 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 = 10 ! 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: Yes, the example is standard conforming. Discussion: Components of A1 can also be referred to from inside INNER. While the derived type T1 from the host scoping unit is inaccessible inside the internal routine INNER, there is no reason why data entities of this derived type that are accessible cannot be referred to. The implicit mapping for the letter C is not specified within the internal routine INNER. So, the implicit mapping is that of the host routine. In the host routine the letter C is mapped to derived type T1 of the host. Therefore the variable C is implicitly declared to be of type T1 from the host. The components of the variable C, C%NAME and C%EMP_NUMBER, can also be referred to in INNER. The following edits clarify the standard with regard to these questions. REFERENCES: ISO/IEC 1539:1991 (E) section 5.1.1.7, 5.3, 12.1.2.2.1 EDITS: 1. In the first paragraph of 5.1.1.7, change "is specified" to "is declared explicitly". [43:22] 2. In paragraph 5 of 5.3 after "provided the mapping is not null.", insert the new sentence: "Note that the mapping can be to a derived type that is inaccessible in the local scope if the derived type is accessible to the host scope." [54:35] 3. In paragraph 3 of 12.1.2.2.1 after "prior to the DATA statement.", insert a new paragraph: [164:25] "If a derived type name of a host is inaccessible, data entities of that type or subobjects of such data entities still can be accessible." SUBMITTED BY: Larry Rolison, 120-LRR-5 (120.030) LAST SIGNIFICANT CHANGE: 93-07-16 000032 edit 3 subsumed by 000082 HISTORY: 096, ul23 (jw note) 120-TMRE-2 (120.075) 92-035 Questioned by 92-049(p14) Questioned by 92-050(p4) Questioned by m121 Revised but rejected 92-280 Revised response proposed m123 approved uc N881 WG5 approval X3J3/93-234 m126 edit 3 is subsumed and superceded by interpretation 82 -------------------------------------------------------------------------------- NUMBER: 000033 TITLE: Interface blocks with the same name in a program KEYWORDS: generic interface, module, USE statement DEFECT TYPE: Interpretation STATUS: Published QUESTION: See, also, item 000034 which this item subsumes. See, also, item 000035 which this item subsumes. Question 1: In the following program, both interface blocks have the same generic 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 ... 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; USE MOD_2 ! Program accesses both modules. ... END Question 2: If the following module is added to the above example and the USE statement in the main program is changed to "USE MOD_1; USE MOD_2; USE 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 Question 3: If the program and modules shown above 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 1: No. Function F2 is still accessible but only by its specific name. ANSWER 2: Yes, but not for the reason implied by the question. ANSWER 3: Yes. The program will have access to functions F1 and F2 but only by their specific names. 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. This 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). When the example is modified as specified by Question 2, 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. When the example is modified as specified by Question 3, 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. Therefore, both the function F1 and F2 are accessible within the program EXAMPLE_1, but only by their specific names. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.2.3, 11.3.2 EDITS: None. SUBMITTED BY: Larry Rolison, 120-LRR-6 (120.031) HISTORY: 120-TMRE-3 (120.076) Included into S20 as three items (33-35). Recombined in 92-308. Revised in response to ballot comments in 93-082. m124 Approved by unanimous consent 94-160 m129 WG5 ballot approved with edit request from Japan 94-168 m129 WG5 requested edit to answer 3. N981 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000034 TITLE: subsumed by 000033, Interface Blocks with the Same Name in a Program - II KEYWORDS: DEFECT TYPE: STATUS: Subsumed 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: EDITS: SUBMITTED BY: Larry Rolison, 120-LRR-6 (120.031) Part 2 HISTORY: 120-TMRE-3 (120.076) subsumed by 000033 -------------------------------------------------------------------------------- NUMBER: 000035 TITLE: subsumed by 000033, Interface Blocks with the Same Name in a Program -III KEYWORDS: DEFECT TYPE: STATUS: Subsumed 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: EDITS: SUBMITTED BY: Larry Rolison, 120-LRR-6 (120.031) Part 3 HISTORY: 120-TMRE-3 (120.076) subsumed by 000033 -------------------------------------------------------------------------------- NUMBER: 000036 TITLE: Pointer to an assumed-size array KEYWORDS: array assumed-size, pointer assignment statement DEFECT TYPE: Interpretation STATUS: Published 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, third paragraph, second sentence. EDITS: None. SUBMITTED BY: Larry Rolison, 120-LRR-7 (120.032) HISTORY: 120-RRR-2A (120.087A) Approved in ballot 92-182 m125 edits from WG5 ballot N865 comments N881 WG5 approval 93-150 m125 edits from WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000037 TITLE: Use of array sections in pointer assignment statements KEYWORDS: pointer assignment statement, array sections DEFECT TYPE: Interpretation STATUS: Published 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 EDITS: None. SUBMITTED BY: Larry Rolison, 120-LRR-7 (120.032) HISTORY: 120-RRR-2A (120.087A) Approved in ballot 92-182 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000038 TITLE: Same interface body in multiple generic interface blocks KEYWORDS: interface body, generic interface, scoping unit DEFECT TYPE: Interpretation STATUS: Published QUESTION: Part 1. Is 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; USE 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 or by adding a rename or only option to one of the USE statements. EDITS: None. SUBMITTED BY: Larry 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 92-267r m123 Edit approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000039 TITLE: Association of a pointer actual argument with a dummy argument KEYWORDS: pointer, argument - actual, argument - dummy, argument association DEFECT TYPE: Erratum STATUS: Published QUESTION: When a pointer is passed as an actual argument, is the intent of the standard as follows: Dereferencing of the pointer is dependent on the interface of the called procedure. That is, if the dummy argument is known to be a pointer (with matching type, etc.) then the pointer actual argument is NOT dereferenced - the pointer itself is passed. Conversely, if the dummy argument is unknown or is known to not be a pointer then the pointer actual 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 its target when the dummy argument is a nonpointer. Another valid implementation would be to pass a descriptor in both cases. Since the notion of referencing and dereferencing pointers is implementation dependent, the standard does not use these terms when discussing pointers and targets. The standard does state when a pointer's association status may change (pointer assignment, allocation, deallocation, nullification, and association with a dummy argument which is a pointer) and several cases where a pointer name refers to the associated target object (assignment as primary in an expression, and an I/O list). There is also an example of a pointer actual argument associated with a nonpointer dummy argument in section 12.5.2.9. The corrections indicated below clarify the rules and meaning of associating a pointer actual argument with a nonpointer dummy argument. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1.2.4.3, 7.1.4.1, 7.5.1.5, 9.4.4.4, 12.4.1.1, & 12.5.2.9 EDITS: 1. Delete the penultimate (tenth) paragraph of 5.1.2.4.3, "A pointer dummy argument ... argument." [46:41-42] 2. Add the following new paragraph following the current fifth paragraph of section 12.4.1.1: [173:13+] If the dummy argument is not a pointer and the corresponding actual argument is, the actual argument must be currently associated with a target and the dummy argument becomes argument associated with that target. SUBMITTED BY: Larry Rolison, 120-LRR-9 (120.034) HISTORY: 120-JLS-9 (120.079) Passed letter ballot to move to "Ready for WG5" status 92-201 92-228 (jw note) 93-102 m124 Revised response adopted by unanimous consent 93-111 m125 ballot approved with Maine, Martin edits 93-150 m125 edits from X3J3 ballot 94-160 m129 WG5 ballot approved --------------------------------------------------------------------------------