J3/04-377 Date: 18-Sep-2004 To: J3 Members From: interp/Stan Whitlock Subj: J3 Fortran interp letter ballot #9 - due 20-Oct-2004 Enclosed in the nineth letter ballot on Fortran interpretations and the first containing Fortran 2003 interpretations. The rules by which we operate say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 16 Fortran 2003 interpretations are currently "passed by J3 meeting" after J3 meeting #169. This is the letter ballot phase to go from "passed by J3 meeting" to "passed by J3 letter ballot". The following Fortran interpretations are being balloted: Yes No Number Title --- --- F03/0001 Generic type-bound procedures --- --- F03/0002 Component value for pointer components --- --- F03/0003 Referencing deferred bindings --- --- F03/0004 Type-bound procedures and undefined association status --- --- F03/0005 Argument association and the TARGET attribute --- --- F03/0006 Intrinsic assignment and allocatable components --- --- F03/0007 Finalization of structure constructors in specifications --- --- F03/0008 Pointer assignment and arrays --- --- F03/0009 VALUE attribute for passed-object dummy arguments --- --- F03/0010 Unlimited polymorphic pointer/allocatable dummy arguments --- --- F03/0011 Allocating objects of abstract types --- --- F03/0012 Procedure pointers and the EXTERNAL attribute --- --- F03/0013 VALUE attribute for polymorphic dummy arguments --- --- F03/0014 Automatic arrays in interface bodies --- --- F03/0015 TARGET attribute for associate names --- --- F03/0016 Invoking type-bound procedures via array objects The text of these interpretations is attached. Each interpretation starts with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail message} with any comments to j3@j3-fortran.org by 11:59:59PM, PDT, Wednesday, 20-Oct-2004, in order to be counted. Thanks /Stan ------------------------------------------------------------------------ NUMBER: F03/0001 TITLE: Generic type-bound procedures KEYWORDS: generic, type-bound DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Section 12.4.5 discusses how a in a (R1219) is resolved if the is that of a generic type-bound procedure. This seems to imply that it is intended to be possible to invoke a generic type-bound procedure (which one might have guessed anyway :-)). However, according to the bnf in 4.5.4, only a specific binding has a . The in is a list of specific binding names. Thus the discussion of generic s in 12.4.5 is moot, there being no such things. Consequently, R1219 appears to provide no syntax for invoking generic type-bound procedures. Should R1219 and 12.4.5 be modified to allow a reference of the form " % " where is the name of a generic binding of the declared type of ? ANSWER: No. As is, the standard provides syntax for invoking a generic type-bound procedure. DISCUSSION: There is no explicit BNF definition of in 4.5.4 or elsewhere; therefore it's use in R1219 is, by our implicit BNF rules, simply equivalent to with the only constraints being those specified for R1219. In R1219, is allowed and indeed required to be a "binding name". This is a technical term defined in 4.5.4 (at [57:23-26]) to mean both the of a specific type- bound procedure and the of a generic type-bound procedure. Thus all of the analysis in the question is based on a false premise. EDITS: None. SUBMITTED BY: Richard Maine HISTORY: J3/04-320 m169 Submitted J3/04-320r1 m169 Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0002 TITLE: Component value for pointer components KEYWORDS: component, value, pointer DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: According to 4.5.7, the component value for an allocatable component includes the bounds if the component is allocated. However, no mention is made of the bounds of pointer components. It is possible for pointers with different bounds to be associated with the same target (13.7.13); therefore, I conclude that the bounds are not part of the association. Is it standard conforming for a processor to print 1 as a result of the following program? program me type t integer, pointer :: p(:) end type t type(t) :: x allocate(x%p(3:5)) call sub(x) contains subroutine sub(y) type(t), value :: y write (*,*) lbound(y%p) end subroutine sub end program me ANSWER: No, a processor is required to print 3 as a result of the above program. The conclusion that the bounds are not part of a pointer's association is incorrect. DISCUSSION: The analysis appears to be based on the theory that the ASSOCIATED intrinsic function defines what is meant by "pointer association". In fact, the 1-argument form of that function only returns the pointer association *status*, and the 2-argument form only tests the association between a pointer and a target - it does not compare the pointer association of two pointers. If the bounds were not part of "pointer association", non-component pointers would be similarly faulty. Pointer association is established by the ALLOCATE statement (6.3.1.2) and pointer assignment (7.4.2.1). Both of these specify array bounds for the association. These are the defining sections for pointer association, and therefore, the bounds form part of that association. It could be recommended that a future revision of the standard contain a more comprehensible definition of the term "pointer association". EDITS: None. SUBMITTED BY: Richard Maine HISTORY: J3/04-321 m169 Submitted J3/04-321r1 m169 Passed by J3 meeting ------------------------------------------------------------------------ If interp F03/0004 passes, this interp becomes subsumed. NUMBER: F03/0003 TITLE: Referencing deferred bindings KEYWORDS: Type-bound procedure, deferred binding DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: I thought that the intent was that it would be impossible to reference a deferred binding. However, it doesn't appear to me that this intent was achieved. Consider the following program (Sorry, but I don't have any compilers up to syntax-checking this). module defer type, abstract :: t contains procedure (sub), nopass, deferred :: deferred_proc end type t type, extends(t) :: t2 contains procedure :: deferred_proc => sub2 end type t2 contains subroutine sub write (*,*) 'Hello.' end subroutine sub subroutine sub2 write (*,*) 'Goodbye.' end subroutine sub2 end module defer program p use defer class(t), pointer :: x nullify(x) call x%deferred_proc end program p Is this a valid program? If not, what restriction of the standard does it violate? Note that x%deferred_proc does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, [83:23-24] does not prohibit this. Nor is it clear that there is an intent to prohibit invocation of type-bound procedures for disassociated pointer objects; except in the case of deferred bindings, this seems well-defined and potentially useful. Because x is disassociated, its dynamic type is the same as its declared type, thus making the interpretation of x%nondeferred_proc reasonably clear. ANSWER: No, this was not intended to be a valid program. An edit is supplied to clarify this situation. EDITS: All edits refer to 04-007. [266:24+] Insert "C1224a (R1219) If is that of a deferred type-bound procedure, or is generically resolved to a specific deferred type-bound procedure, shall not be a disassociated pointer, an undefined pointer, or an unallocated allocatable variable." SUBMITTED BY: Richard Maine HISTORY: J3/04-322 m169 Submitted J3/04-322r1 m169 Passed by J3 meeting ------------------------------------------------------------------------ If this interp passes, its subsumes interp F03/0003. NUMBER: F03/0004 TITLE: Type-bound procedures and undefined association status KEYWORDS: Type-bound procedure, dynamic type DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: It appears that the dynamic type is undefined for a pointer with undefined association status. This impacts type-bound procedures. Consider the following program. module undefined type :: t contains procedure, nopass :: nondeferred_proc => sub end type t type, extends(t) :: t2 contains procedure, nopass :: nondeferred_proc => sub2 end type t2 contains subroutine sub write (*,*) 'Hello.' end subroutine sub subroutine sub2 write (*,*) 'Goodbye.' end subroutine sub2 end module undefined program p use undefined class(t), pointer :: x call x%nondeferred_proc end program p Is this a valid program? If not, what restriction of the standard does it violate? If so, what does it print. Note that x%nondeferred_proc does not require the value of x (4.5.7) and thus is not a reference to x (2.5.6). Therefore, [83:23-24] does not prohibit this. If x were disassociated, its dynamic type would be t and the interpretation of this would be reasonably clear. However, the standard does not appear to specify the dynamic type of x when its association status is undefined. Nor can I find any prohibition that applies to this case. ANSWER: No, the program is not valid, because the standard does not establish an interpretation of it. An edit is supplied to clarify this. Furthermore, the case with a disassociated pointer was not intended to be valid. An edit is supplied to correct this oversight. DISCUSSION: Access to object-bound procedures (a.k.a. procedure pointer components) always require there to be an object. Access to type-bound procedures of an object was intended to require this too, but the effect of the NOPASS attribute on this was overlooked. EDITS: All edits refer to 04-007. [266:24+] Insert new constraint "C1224a (R1219) If is a pointer, it shall be associated. If is allocatable, it shall be allocated." SUBMITTED BY: Richard Maine HISTORY: J3/04-323 m169 Submitted J3/04-323r1 m169 Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0005 TITLE: Argument association and the TARGET attribute KEYWORDS: argument, association, target, pointer DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Fortran 95 allowed the following program to print "T". Fortran 2003 does not appear to allow this. module m integer, pointer :: i_ptr contains subroutine sub(j) integer j call sub2(j) end subroutine subroutine sub2(j2) integer, target :: j2 print *, associated (i_ptr, j2) end subroutine end module program foo use m integer, target :: i i_ptr => i call sub(i) end program Fortran 95 stated, in section 12.4.1.1, on page 200: If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. If such a dummy argument is associated with a dummy argument with the TARGET attribute, whether any pointers associated with the original actual argument become associated with the dummy argument with the TARGET attribute is processor dependent. Fortran 2003 (04-007) states, in section 12.4.1.2, on page 269: If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. If such a dummy argument is associated with an actual argument that is a dummy argument with the TARGET attribute, whether any pointers associated with the original actual argument become associated with the dummy argument with the TARGET attribute is processor dependent. It's clear in this example that j is not associated with i_ptr, because it doesn't have the TARGET attribute. The dummy argument j2 with the TARGET attribute falls into the case described by the second sentence quoted from Fortran 95. It does not fall into the case described by the second sentence quoted from Fortran 2003, since j is not associated with an actual argument that is a dummy argument with the TARGET attribute. It appears that the second sentence in Fortran 2003 gets things backwards. Was it intended in the example above that the program should be allowed to print "T"? ANSWER: Yes. An edit is supplied to correct this error. EDITS: All edits refer to 04-007. [270:1-2] Change "associated with an actual argument that is" to "used as an actual argument that is associated with". REFERENCES: 02-148r1 inserted this clarification but it is incorrect. SUBMITTED BY: Rob James HISTORY: 04-330 m169 Submitted 04-330r1 m169 Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0006 TITLE: Intrinsic assignment and allocatable components KEYWORDS: assignment, allocatable DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following code: type t integer, allocatable :: i end type type(t) :: x allocate(x%i) x = x print *, allocated(x%i) end In the intrinsic assignment, it is unclear whether the value of the expression on the right-hand side of the assignment should be determined before the any part of the left-hand side becomes defined. Section 7.4.1.3 of Fortran 2003 states: The execution of the assignment shall have the same effect as if the evaluation of all operations in and occurred before any portion of is defined by the assignment. In this case, there are no operations in , so this sentence does not apply. There doesn't appear to be anything else to cover this situation, so it appears that in this case, does not have to be evaluated before any part of is defined. If x%i becomes deallocated before the is evaluated, then the call to the ALLOCATED intrinsic in this example would return the value .false. Was it intended that this program could print "F"? ANSWER: No. It was intended that the in an intrinsic assignment must be evaluated before any part of the is defined. An edit is supplied to correct this oversight. EDITS: All edits refer to 04-007. [139:17] Change "the evaluation of all operations in and " to "the evaluation of and the evaluation of all expressions in ". [141:20,21,22] Before "" insert "the value of", thrice. SUBMITTED BY: Rob James HISTORY: 04-331 m169 Submitted 04-331r1 m169 Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0007 TITLE: Finalization of structure constructors in specifications KEYWORDS: finalization, structure constructor, specification expression DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Paragraphs 3-5 of subclause 4.5.5.2 specify when finalization occurs for function results in executable constructs and in specification expressions. They also specify when finalization occurs for structure constructors in executable constructs. However, structure constructors in specification expressions do not appear to be mentioned. The apparent conclusion would be that structure constructors in specification expressions are not finalized, which seems inconsistent and contrary to the purpose of finalization. Q1. Are structure constructors in specification expressions finalized? If so, when? The phrase "before the first executable statement in a scoping unit" is used in two places in the standard (4.5.5.2 and at [116:8] after note 6.24) to describe the first thing executed in a scoping unit. This phrase has two problems. First, not all executable statements can be executed as single statements; the description of execution sequence is in terms of executable constructs rather than executable statements. (See 2.3.4, 8.1.1.3, and 12.5.2.0). Although this distinction seems unlikely to lead to confusion, the terminology seems inconsistent. Second, and more problematic, is that the first executable statement or construct in a scoping unit is not necessarily the first thing executed in the scoping unit; nor is it necessarily executed only once. An entry statement may cause execution to start at some other executable construct, in which case one might wonder whether the specified actions ever happen. A goto might cause the construct to be executed multiple times, in which case one might wonder whether the specified actions happen again. I seriously doubt that either of these represent the intent. Q2. If an event is specified to occcur before the first executable statement in a scoping unit, then for a single execution of that scoping unit, may the event happen zero times, multiple times, or after the execution of some other executable statement or construct in the scoping unit? ANSWER: A1. Yes, structure constructors in specification expressions are finalized. Just as with function results in specification expressions, this finalization occurs before execution of the executable constructs in the scoping unit. This was an accidental omission from the standard. Edits are supplied to correct it. A2. No. The intent is to describe events that happen once and only once per execution of a procedure defined by a scoping unit. Edits are supplied to state this more precisely. EDITS: All edits refer to 04-007. [59:30] and [116:8] Change "first executable statement" -> "executable constructs" [59:30+] Insert new para "If a specification expression in a scoping unit references a structure constructor, the entity created by the structure constructor is finalized before execution of the executable constructs in the scoping unit." SUBMITTED BY: Richard Maine HISTORY: 04-332 m169 Submitted; Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0008 TITLE: Pointer assignment and arrays KEYWORDS: pointer assignment, array, data-ref DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: There appears to be no explicit requirement that the s in R736 and R741 be scalar. If data-pointer-object and proc-component ref were data-refs, then C614 would prohibit the s from being arrays. However, although the syntax looks like a special case of a data-ref, nothing appears to say that R736 and R741 actually constitute data-refs. The standard gives no interpretation as to what the meaning would be in the case of an array. Even when variable is a scalar, the standard does not appear to define what the properties (such as type and shape) of a data-pointer-object or proc-pointer-object are in the case where the syntax has a "%". All we have is a syntax with no established meaning. Q1. Is the in R736 or R741 allowed to be an array? Q2. Is the interpretation of the forms in R736 and R741 the same as that of a data-ref? ANSWER: A1. No. The standard provides no interpretation of what such a form would mean. Therefore, by the first sentence of 1.5, it is not standard-conforming. Edits are provided to make this prohibition more direct. A2. Yes. EDITS: All edits refer to 04-007. [143:12,35] Insert "" before "", twice. SUBMITTED BY: Richard Maine HISTORY: 04-333 m169 Submitted 04-333r1 m169 Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0009 TITLE: VALUE attribute for passed-object dummy arguments KEYWORDS: VALUE, passed-object, dummy argument DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider the following program: module m type t integer :: id contains procedure :: doThings => doThingsT end type contains subroutine doThingsT (a) class(t), value :: a a%id = 5 end subroutine end module program p use m type(t) :: z = t(1) call z%doThings print *, z%id end program Section 12.4.1.1 of Fortran 2003 states: In a reference to a type-bound procedure that has a passed-object dummy argument (4.5.3.3), the of the or is associated, as an actual argument, with the passed-object dummy argument. This seems to be contrary to the idea of the VALUE attribute. For argument association where the dummy argument has the VALUE attribute, section 12.4.1.2 of Fortran 2003 states: If the dummy argument has the VALUE attribute it becomes associated with a definable anonymous data object whose initial value is that of the actual argument. Subsequent changes to the value or definition status of the dummy argument do not affect the actual argument. It looks like the passed-object dummy argument is argument associated with the object z itself, rather than an anonymous data object whose initial value is that of z. What value should the above program print? ANSWER: This program was not intended to be standard-conforming; the VALUE attribute is not appropriate for a passed-object dummy argument. Edits are supplied to clarify this situation. DISCUSSION: As perhaps evidenced by its own name, the passed-object dummy argument was intended to be THE object through which the type-bound procedure was invoked. It performs the same function as the "self" or "this" variable of other object-oriented languages. EDITS: All edits refer to 04-007. [53:1] Append to constraint "It shall not have the VALUE attribute." SUBMITTED BY: Rob James HISTORY: 04-334 m169 Submitted 04-334r1 m169 Revised 04-334r2 m169 Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0010 TITLE: Unlimited polymorphic pointer/allocatable dummy arguments KEYWORDS: polymorphism, POINTER, ALLOCATABLE, argument DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following program: module m type t integer i end type contains subroutine s (x) class (*), pointer, intent(inout) :: x end subroutine end module program p use m class (*), pointer :: up class (t), pointer :: lp call s (lp) call s (up) end program Section 12.4.1.2 states: If a dummy argument is allocatable or a pointer, the associated actual argument shall be polymorphic if and only if the dummy argument is polymorphic, and the declared type of the actual argument shall be the same as the declared type of the dummy argument. Section 5.1.1.2 states: An object declared with the CLASS(*) specifier is an unlimited polymorphic object. An unlimited polymorphic entity is not declared to have a type. It is not considered to have the same declared type as any other entity, including another unlimited polymorphic entity. Taken together, these two statements seem to imply that no unlimited polymorphic dummy argument that has the ALLOCATABLE or POINTER attribute can be associated with any actual argument. Are either of the procedure calls in the given example standard-conforming? ANSWER: The first procedure call is not standard-conforming. The second procedure call was intended to be standard-conforming. Edits are provided to correct this oversight. EDITS: All edits refer to 04-007. [268:23] Before "the declared", insert "either both the actual and dummy argument shall be unlimited polymorphic, or". SUBMITTED BY: Rob James HISTORY: 04-335 m169 Submitted; Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0011 TITLE: Allocating objects of abstract types KEYWORDS: ALLOCATE, ABSTRACT DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following code: module m type, abstract :: t integer :: i end type class(t), allocatable :: d end module program foo use m allocate(d) end One cannot declare a non-polymorphic object of an abstract type. Similarly, a polymorphic object should not be allocated with a dynamic type that is abstract. A in an allocate statement cannot specify an abstract type. But the effect of the allocate statement in the example above is the same as if a specifying an abstract type appeared in the allocate statement, which would not be standard-conforming. Was this example intended to be standard-conforming? ANSWER: No, this example was not intended to be standard-conforming. An edit is provided to correct this oversight. EDITS: All edits refer to 04-007. [111:11-12] Change the words "unlimited polymorphic" in the constraint to "unlimited polymorphic or is of abstract type" so that it reads: C625 (R623) If any is unlimited polymorphic or is of abstract type, either or SOURCE= shall appear. SUBMITTED BY: Rob James HISTORY: 04-336 m169 Submitted 04-336r2 m169 Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0012 TITLE: Procedure pointers and the EXTERNAL attribute KEYWORDS: Procedure pointers, EXTERNAL DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is the following program unit standard conforming? SUBROUTINE SUB ( RPP ) REAL, EXTERNAL, POINTER :: RPP EXTERNAL, POINTER :: PP PROCEDURE(REAL), POINTER :: PPP => NULL() END SUBROUTINE SUB The last sentence of "5.1.2.6 EXTERNAL attribute" appears to indicate that it is allowed: "A procedure that has both the EXTERNAL and POINTER attributes is a procedure pointer." That the title of subclause 12.2.1.2 is "Characteristics of dummy procedures and dummy procedure pointers" suggests that it is allowed. That subclause continues "... whether it is a pointer, ..." so it was clearly envisioned that at least dummy procedures could have the POINTER attribute. C1216 appears to require PPP to be allowed: "C1216 (R1214) If => appears in , the procedure entity shall have the pointer attribute." On the other hand, C512 appears to prohibit RPP and PP: "C512 (R501) If the POINTER attribute is specified, the ALLOCATABLE, TARGET, EXTERNAL, or INTRINSIC attribute shall not be specified." and a conspiracy of C512, the second sentence of subclause 5.1.2.6 "This [EXTERNAL] attribute may also be specified by ... a ..." and the first paragraph of subclause 5.2 "The combination of attributes that may be specified for a particular entity is subject to the same restrictions ... regardless of the method of specification. This also applies to the PROCEDURE, EXTERNAL and INTRINSIC statements." appears to prohibit PPP. ANSWER: The program unit is standard conforming. It was an oversight that the EXTERNAL attribute was not removed from C512 during the development of the procedure pointer facility. It is not helpful that the last sentence of the first paragraph of subclause 5.2 refers to "PROCEDURE ... statements" where it should refer to "procedure declaration ... statements." EDIT: All edits refer to 04-007. At [04-007:72:28], delete ", EXTERNAL" from C512. At [04-007:86:1], replace the last sentence of the first paragraph of subclause 5.2 by "This also applies to procedure declaration statements, and to EXTERNAL and INTRINSIC statements." SUBMITTED BY: Van Snyder HISTORY: 04-358 m169 submitted 04-358r2 m169 Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0013 TITLE: VALUE attribute for polymorphic dummy arguments KEYWORDS: VALUE, CLASS DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The VALUE attribute is not allowed for any dummy argument that has a (visible) nonconstant length type parameter. (Or indeed for any array.) The intent appears to be to restrict VALUE arguments to being of constant size. However consider: SUBROUTINE S(x) CLASS(t),VALUE :: x ... There is no requirement that X not be polymorphic, so this requires copying a variable (known only at runtime) sized value, in violation of the apparent intent of the other restrictions. For example, X might have an invisible nonconstant length type parameter in its dynamic type; this allows the user to bypass that particular VALUE restriction simply by obfuscating his code so that the nonconstant length type parameter is in the dynamic type but not in the declared type. Should there be a restriction that a VALUE dummy argument not be polymorphic? ANSWER: Yes, this restriction was accidentally omitted. An edit is provided to fix this oversight. DISCUSSION: The deduced intent is apparent from the rejection of the UK comment C7 on the FCD ballot. WG5 agreed that the existing constraint was inconsistent, but felt that there were potential implementation concerns with deleting it completely. Therefore, the constraint was instead modified to a simpler and more consistent form. EDITS: All edits refer to 04-007. [72:23] Append "It shall not have the VALUE attribute." SUBMITTED BY: Malcolm Cohen HISTORY: J3/04-360 m169 Submitted; Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0014 TITLE: Automatic arrays in interface bodies KEYWORDS: automatic array, interface body DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Is the following program standard-conforming. program main interface subroutine sub(n) integer, intent(in) :: n real :: x(n) end subroutine sub end interface call sub(2) end program main subroutine sub(n) integer, intent(in) :: n real :: x(n) write (*,*) size(x) end subroutine sub The potential problem is the declaration of X in the interface body. According to C542 "An explicit-shape array whose bounds are not initialization expressions shall be a dummy argument, a function result, or an automatic array of a procedure." The definition of an automatic array is "An automatic array is an explicit-shape array that is declared in a subprogram, is not a dummy argument, and has bounds that are not initialization expressions." Although the X in subroutine sub fits this definition, the X in the interface body does not because an interface body is not a subprogram. In 12.3.2.1, at [259:36-37], we have "The specification part of an interface body may specify attributes or define values for data entities that do not determine characteristics of the procedure. Such specifications have no effect." The presumed reason for this is to allow the specification part of a procedure to be copied into an interface body. If the declarations of automatic arrays cannot be so copied, that would appear to negate the reason for the feature. ANSWER: Yes. This was intended to be standard conforming. Edits are provided to fix this error. EDITS: All edits refer to 04-007. [78:23] "subprogram" -> "subprogram or interface body" [78:21-22] "shall be... procedure." -> "may be declared only in a subprogram or interface body." SUBMITTED BY: Richard Maine HISTORY: 04-361 m169 Submitted; Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0015 TITLE: TARGET attribute for associate names KEYWORDS: TARGET, POINTER, ASSOCIATE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Consider the following code: program assocTarget integer, pointer :: first_ptr integer, pointer :: second_ptr integer, target :: tgt tgt = 20 first_ptr => tgt associate(aname => first_ptr) second_ptr => aname end associate end Section 16.4.1.5 (Construct association) indicates that the associating entity aname is associated with the target of first_ptr. However, section 8.1.4.3 (Attributes of associate names) indicates that aname does not have the TARGET attribute, since this would only be true if the selector had the TARGET attribute. Was this example intended to be standard-conforming? ANSWER: Yes, this example was intended to be standard-conforming. Edits are supplied to correct this oversight. EDITS: All edits refer to 04-007. [161:18-19] Remove ", TARGET,". [161:19] After "attribute.", insert the following sentence: The associating entity has the TARGET attribute if and only if the selector is a variable and has either the TARGET or POINTER attribute. SUBMITTED BY: Rob James HISTORY: 04-366 m169 Submitted 04-366r1 m169 Passed by J3 meeting ------------------------------------------------------------------------ NUMBER: F03/0016 TITLE: Invoking type-bound procedures via array objects KEYWORDS: elemental, type-bound procedure, NOPASS attribute DEFECT TYPE:Erratum STATUS: Passed by J3 meeting QUESTION: Consider INTERFACE SUBROUTINE sub; END END INTERFACE TYPE t CONTAINS PROCEDURE,NOPASS :: p => sub END TYPE TYPE(t) x(100) CALL x%p END (1) Is this program-unit standard-conforming? If so, how many times is SUB invoked? (2) If SUB has the ELEMENTAL attribute, does this change its standard conformance? If it is conforming, how many times is it executed? Consider: TYPE t ... CONTAINS PROCEDURE ep => emp END TYPE ... ELEMENTAL SUBROUTINE emp(x) CLASS(t),INTENT(INOUT) :: x ... END SUBROUTINE ... TYPE(t) a(10) CALL a%ep (3) Is this fragment standard-conforming, and if so, is "CALL a%ep" equivalent to "CALL emp(a)"? Consider: INTERFACE ELEMENTAL SUBROUTINE esub(r); REAL,INTENT(IN) :: r; END END INTERFACE TYPE t CONTAINS PROCEDURE,NOPASS :: ep => esub END TYPE TYPE(t) x(100) REAL y(50) CALL x%ep(y) END (4) Is this standard-conforming? If so, is ESUB invoked 50 times or 100 times? ANSWER: (1) No. (2) No. (3) Yes. (4) No. If the invoking object is an array, the type-bound procedure must be elemental and have the PASS attribute. An edit is supplied to clarify this. DISCUSSION: The invoking object can only enable elementalisation if it is an actual argument, i.e. if the type-bound procedure has the PASS attribute. If the type-bound procedure does not have both the PASS and ELEMENTAL attributes, the invoking object shall be scalar. EDITS: All edits refer to 04-007. [266:24+] Insert new constraint "C1224a (R1219) If is an array, the referenced type-bound procedure shall have the PASS attribute." SUBMITTED BY: Malcolm Cohen HISTORY: 04-368 m169 Submitted; Passed by J3 meeting ------------------------------------------------------------------------