From owner-sc22wg5@open-std.org Tue Feb 28 18:57:30 2006 Return-Path: X-Original-To: sc22wg5-domo2 Delivered-To: sc22wg5-domo2@open-std.org Received: by open-std.org (Postfix, from userid 521) id DB1EF1B5BC; Tue, 28 Feb 2006 18:57:30 +0000 (UTC) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from dkuug.dk (ptah.dkuug.dk [195.215.30.66]) by open-std.org (Postfix) with ESMTP id 021021ADD7 for ; Tue, 28 Feb 2006 18:57:28 +0000 (UTC) Received: from nmta3.jpl.nasa.gov (nmta3.jpl.nasa.gov [137.78.160.108]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id k1SIuGZb092171 for ; Tue, 28 Feb 2006 19:56:28 +0100 (CET) (envelope-from van.snyder@jpl.nasa.gov) Received: from xmta2.jpl.nasa.gov (xmta2.jpl.nasa.gov [137.78.160.56]) by nmta3.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1SIuAmw012057; Tue, 28 Feb 2006 10:56:10 -0800 Received: from mls.jpl.nasa.gov (mls.jpl.nasa.gov [137.79.7.84]) by xmta2.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1SIu9G7012810; Tue, 28 Feb 2006 10:56:10 -0800 Received: from math.jpl.nasa.gov (math.jpl.nasa.gov [137.79.7.57]) by mls.jpl.nasa.gov (8.12.10+Sun/8.12.9) with ESMTP id k1SIsQOF020151; Tue, 28 Feb 2006 10:54:26 -0800 (PST) Received: from math.jpl.nasa.gov (localhost.localdomain [127.0.0.1]) by math.jpl.nasa.gov (8.13.1/8.12.11) with ESMTP id k1SIu9Il019114; Tue, 28 Feb 2006 10:56:09 -0800 Received: (from vsnyder@localhost) by math.jpl.nasa.gov (8.13.1/8.12.11/Submit) id k1SIu9C6019113; Tue, 28 Feb 2006 10:56:09 -0800 X-Authentication-Warning: math.jpl.nasa.gov: vsnyder set sender to van.snyder@jpl.nasa.gov using -f Subject: Re: (j3.2005) (SC22WG5.3351) WG5 interps letter ballot From: Van Snyder Reply-To: van.snyder@jpl.nasa.gov To: j.k.reid@rl.ac.uk Cc: WG5 In-Reply-To: <20060228173731.8EB711B5BA@open-std.org> References: <20060228173731.8EB711B5BA@open-std.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 28 Feb 2006 10:56:08 -0800 Message-Id: <1141152968.25306.185.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) X-Source-IP: mls.jpl.nasa.gov [137.79.7.84] X-Source-Sender: van.snyder@jpl.nasa.gov X-AUTH: Internal IP X-Spam-Score: 0 () Sender: owner-sc22wg5@open-std.org Precedence: bulk On Tue, 2006-02-28 at 17:36 +0000, John Reid wrote: > WG5, > > Here is a WG5 letter ballot on interpretations to run until 8 a.m (UK time) on > March 31. Anyone may vote. > > Best wishes, > > John. > plain text document attachment (N1657.txt) > ISO/IEC JTC1/SC22/WG5 N1657 > > WG5 letter ballot 3 on Fortran 2003 interpretations > John Reid, 28 February 2006 > > > This is the third set of draft interpretations for Fortran 2003. They > have all been approved in a J3 letter ballot. > > The rules we operate on say: > > 4. The chair of J3/interp gathers all interp answers that are marked > "passed by J3 letter ballot" and forwards them to the WG5 convenor. > The WG5 convenor holds a ballot of individual members; a no vote > must be accompanied by an explanation of the changes necessary to > change the member's vote to yes. The answers that pass this ballot > become "WG5 approved". > > J3/interp reserves the right to recall an interp answer for more > study even if the answer passes. > > 5. "WG5 approved" answers are processed into a corrigendum document by > taking the edits from the interp answers and putting them in the > format required by ISO. A WG5 vote is made on forwarding the > corrigendum to SC22. > > The following Fortran 2003 interpretations are being balloted: > > Yes No Number Title > -Y- --- F03/0008 Pointer assignment and arrays > -Y- --- F03/0012 Procedure pointers and the EXTERNAL attribute > -Y- --- F03/0018 Multiple identical specific procedures in > type-bound generic interfaces > -Y- --- F03/0019 Multiple identical specific procedures in > generic interface blocks > -Y- --- F03/0020 Kinds of intrinsic type parameters > -Y- --- F03/0023 IEEE_SET/GET_UNDERFLOW_MODE > -Y- --- F03/0025 Abstract types in CLASS IS type guard statements > -Y- --- F03/0026 Intrinsic types in CLASS IS type guard statements > -Y- --- F03/0027 Assumed character length in type guard statements > -Y- --- F03/0028 Commas in complex namelist output > -Y- --- F03/0029 Negative zero and intrinsic functions > -C- --- F03/0045 Finalization and assumed-sized > arguments with INTENT(OUT) > -Y- --- F03/0056 Null input values and list-directed UDDTIO > -Y- --- F03/0057 Namelist I/O and UDDTIO > -Y- --- F03/0058 Recursive namelist output > -C- --- F03/0060 Default initialization of INTENT(OUT), > assumed-size arrays {subsumed by F03/0045} > -Y- --- F03/0061 Polymorphism and explicit-shape or > assumed-size dummy arguments > -Y- --- F03/0062 Finalization of array constructors > _Y_ ___ F03/0063 Procedure pointers in BLOCK DATA program units > -Y- --- F03/0066 Precision of operation > -Y- --- F03/0067 Accuracy of conversion of real literal constants > -Y- --- F03/0068 First character of namelist output records > -Y- --- F03/0069 Procedure pointers in defined assignment > -Y- --- F03/0070 Can child I/O statements be advancing I/O > statements? > -C- --- F03/0072 Default initialization for "automatic" components Comments: Interp F03/0045 states that it subsumes interp F03/0060. Are we balloting both in case 0045 fails and 0060 passes? Interp F03/0072 has an answer to Q2, which is not explicitly noted in the "QUESTION" section. For clarity of the historical record, the last sentence of the "QUESTION" section should be a separate paragraph, beginning "Q2." > 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 mail message} to > > sc22wg5@dkuug.dk > > by 8 a.m (UK time) on Friday, 31 March 2006, in order to be counted. > > Thanks, > > John. > > > > ====================================================================== > Part 1: Fortran 2003 Interpretation Requests read for WG5 > ====================================================================== > > NUMBER: F03/0008 > TITLE: Pointer assignment and arrays > KEYWORDS: pointer assignment, array, data-ref > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > 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,24,35,37] Insert "" before "", four times. > > SUBMITTED BY: Richard Maine > > HISTORY: 04-333 m169 F03/0008 Submitted > 04-333r1 m169 Passed by J3 meeting > 04-418r1 m170 Failed J3 letter ballot #9 > 04-421 m170 Revised - Passed by J3 meeting > 05-146 m171 Passed J3 letter ballot #10 > > ---------------------------------------------------------------------- > > NUMBER: F03/0012 > TITLE: Procedure pointers and the EXTERNAL attribute > KEYWORDS: Procedure pointers, EXTERNAL > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > Is the following program unit standard conforming? > > SUBROUTINE SUB ( RPP ) > REAL, EXTERNAL, POINTER :: RPP > EXTERNAL :: PP > 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 [264:30] appears to require PPP to be allowed: > > "C1216 (R1214) If => appears in , the procedure entity > shall have the pointer attribute." > > On the other hand, A conspiracy of C512 [72:28-29] > > "C512 (R501) If the POINTER attribute is specified, the ALLOCATABLE, > TARGET, EXTERNAL, or INTRINSIC attribute shall not be > specified." > > the second sentence of subclause 5.1.2.6 [80:38-40] > > "This [EXTERNAL] attribute may also be specified by ... a > ..." > > the first paragraph of subclause 5.2 [85:15ff] > > "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." > > and the last sentence of the first paragraph of 12.3.2.3 [264:8] > > "It [the procedure declaration statement] specifies the EXTERNAL > attribute...." > > appears to completely wipe out procedure pointers (PPP because of the > first paragraph of 12.3.2.3). > > C521 [73:6-7] and C568 [91:5] also appear to prohibit RPP and PP: > > "C521 (R504) The shall be the name of an external > function, a function dummy procedure{, or a statement > function}." > > "C568 (R541) A shall also be declared in a > ." > > But then the first paragraph after R1210 (defining the EXTERNAL > statement) [264:1] appears to allow RPP and PP: > > "Each shall be the name of ... a procedure > pointer...." > > There is also a problem with protected procedure pointers. C535 > clearly envisions their existence: > > "C535 (R501) The PROTECTED attribute is permitted only for a procedure > pointer...." > > while C536 prohibits their existence: > > "C536 (R501) If the PROTECTED attribute is specified, the EXTERNAL ... > attribute shall not be specified." > > ANSWER: > > The discussion of procedure pointers is indeed inconsistent. > > The program unit is intended to be standard conforming. It was an > oversight during the development of the procedure pointer facility > that the EXTERNAL attribute was not removed from C512, that > "procedure pointer" was not added to C521, that C535 and C536 > contradict one another, and that an external statement and specifying > the EXTERNAL attribute in a type declaration statement were not > allowed in C568. It is not helpful that the last sentence of the > first paragraph of subclause 5.2 refers to "PROCEDURE ... statements" > (which could be confused with the PROCEDURE statement in an interface > block) where it should refer to "procedure declaration ... > statements." > > EDITS: > > Delete ", EXTERNAL" from C512 [72:28]. > > Insert ", a procedure pointer" after "dummy procedure" in C521 [73:7]. > > Replace C536 [7:35-36]: > > "C536 (R501) If the PROTECTED attribute is specified, the INTRINSIC or > PARAMETER attribute shall not be specified. If the PROTECTED > and EXTERNAL attributes are specified, the POINTER attribute > shall also be specified." > > Replace the last sentence of the first paragraph of subclause 5.2 > [86:1] by "This also applies to procedure declaration statements, and > to EXTERNAL and INTRINSIC statements." > > Replace C568 [91:5]: > > "C568 (R541) The EXTERNAL attribute (5.1.2.6) shall be explicitly > specified for a ." > > SUBMITTED BY: Van Snyder > > HISTORY: 04-358 m169 F03/0012 Submitted > 04-358r2 m169 Revised > 04-418r1 m170 Failed J3 letter ballot #9 > 04-401r2 m170 Passed by J3 meeting > 05-146 m171 Passed J3 letter ballot #10 > > ---------------------------------------------------------------------- > > NUMBER: F03/0018 > TITLE: Multiple identical specific procedures in type-bound generic > interfaces > KEYWORDS: Type-bound generics > DEFECT TYPE: Clarification > STATUS: Passed by J3 letter ballot > > QUESTION 1: > > Does the following program unit conform to the 2003 standard? > > module M > type T > contains > procedure MyAdd > generic :: operator(+) => myAdd > end type T > type X > contains > procedure, pass(b) :: MyAdd > generic :: operator(+) => myAdd > end type X > contains > integer function MyAdd ( A, B ) > type(t), intent(in) :: A > type(x), intent(in) :: B > end function MyAdd > end module M > > QUESTION 2: > > Does the following program unit conform to the 2003 standard? > > module M > interface operator(+) > procedure MyAdd > end interface > type T > contains > procedure MyAdd > generic :: operator(+) => myAdd > end type T > contains > integer function MyAdd ( A, B ) > type(t), intent(in) :: A > real, intent(in) :: B > end function MyAdd > end module M > > QUESTION 3: > > If the interface block and type definition are exchanged in QUESTION > 2, does the program unit conform to the 2003 standard? > > ANALYSIS: > > The OPERATOR(+) bindings to the types T and X construct a single > generic OPERATOR(+) interface that is a local entity of module M. > They do not construct separate OPERATOR(+) generic interfaces that > are separate local entities of the types. > > 16.2.3 (Restrictions on generic declarations) specifies that it > "contains the rules that shall be satisfied by every pair of specific > procedures that have the same generic identifier within a scoping > unit." > > It is clear that if different functions with identical interfaces > were bound to the types that they would be a "pair of specific > procedures" and the resulting OPERATOR(+) interface would therefore > be prohibited by 16.2.3. > > It is not clear whether the generic bindings bind separate specific > procedures to the OPERATOR(+) generic, or only redundantly bind the > same procedure. If the former, the program units are not standard > conforming because they violate the provisions of 16.2.3. If the > latter, they appear to be standard conforming. > > C1209 (in 12.3.2.1) prohibits a procedure to be bound to a generic > interface more than once in a scoping unit, but only by way of a > PROCEDURE statement in a generic interface block. There is nothing > obviously equivalent in 4.5.4, nor anything that specifies that C1209 > applies to generic bindings to types. It also does not apply between > a generic interface block and a generic interface previously > specified by a generic binding to a type (question 3), since the > latter specific binding is accomplished by a conspiracy of a > and a , not by a > . > > ANSWER: > > The program units conform to the 2003 standard. Multiple bindings of > the same procedure to a generic identifier using a > in a type definition or by a type definition and a generic interface > block do not bind a "pair of specific procedures" to the generic > interface. Indeed, the following type definition is legal: > > type Z > contains > procedure :: MyAdd > generic :: operator(+) => myAdd, operator(+) => myAdd > end type Z > > EDITS: None. > > SUBMITTED BY: Van Snyder > > HISTORY: 04-405 m170 F03/0018 Submitted > 04-405r1 m170 Passed by J3 meeting > 05-146 m171 Passed J3 letter ballot #10 > > ---------------------------------------------------------------------- > > NUMBER: F03/0019 > TITLE: Multiple identical specific procedures in generic interface > blocks > KEYWORDS: Type-bound generics > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION 1: > > Does the following program conform to the 2003 standard? > > program P > interface X > subroutine S ( A ) > integer :: A > end subroutine S > procedure S > end interface X > end program P > > ANALYSIS: > > 16.2.3 (Restrictions on generic declarations) specifies that it > "contains the rules that shall be satisfied by every pair of specific > procedures that have the same generic identifier within a scoping > unit." > > It is not clear whether the interface body and the procedure > statement bind separate specific procedures to the generic > identifier, or only redundantly bind the same procedure. If the > former, the program is not standard conforming because it violates > the provisions of 16.2.3. If the latter, it appears to be standard > conforming. > > C1209 (in 12.3.2.1) prohibits a procedure to be bound to a generic > interface more than once in a scoping unit, but only by way of a > PROCEDURE statement in a generic interface block. > > There is a general rule that nothing shall be declared more than > once. It appears that a procedure statement within an interface block > is not a declaration: 5.1.2.6 (External attribute) specifies that > the external attribute may be specified by an EXTERNAL statement, a > or an interface body that is not in an > abstract interface block. A procedure statement in an interface > block apparently does not specify the external attribute. The > procedure specified by the PROCEDURE statement in the above example > is clearly an external procedure with an explicit interface, so it > satisfies the requirements of C1207. > > ANSWER: > > The program conforms to the 2003 standard. Multiple bindings of the > same procedure to a generic identifier using an interface body and a > procedure statement do not bind a "pair of specific procedures" to > the generic interface. > > Enforcing C1209 is more bother for processors than simply allowing > multiple bindings of a particular specific procedure to a generic > interface. It is unhelpful to users, and can be hurtful if the > multiple bindings are specified by independent generic interfaces and > brought into a scoping unit by use association from different > modules. There was no equivalent constraint in Fortran 90, although > something like it was added by interp F90/000007. The constraint > added there applied only to a single specification part. It's not > clear whether that meant "declared in the same specification part" or > "accessible in the same specification part." When it was put into > Fortran 95, it clearly applied to all accessible generic interfaces > with a particular . Given the multitude of new ways to > bring specific procedures into a generic interface in Fortran 2003, > and that many of those ways allow a specific procedure to be bound to > a generic identifier more than once, this conspicuously lonely > constraint should be removed. Edits are supplied to correct this > oversight. > > EDITS: > > Remove C1209 from 12.3.2.1. > > SUBMITTED BY: Van Snyder > > HISTORY: 04-406 m170 F03/0019 Submitted > 04-406r1 m170 Passed J3 meeting > 05-146 m171 Passed J3 letter ballot #10 > > ---------------------------------------------------------------------- > > NUMBER: F03/0020 > TITLE: Kinds of intrinsic type parameters > KEYWORDS: type parameter, kind, intrinsic type > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > Q1. What are the kinds of the type parameters for intrinsic types? > > In most contexts, it doesn't matter. Fortran 95 did not even > have the concept of the kind of a type parameter or a context > in which such a thing could be detected in a > standard-conforming program. Fortran 2003 added the concept > in support of derived types. It also added a syntax which > exposes the question for intrinsic types. > > Q2. What is the KIND of a type parameter inquiry? > > Q3. For example, consider the program > > program what_kind > character c > write (*,*) kind(c%kind) == kind(0) > write (*,*) kind(c%len) == kind(0) > end > > Are both write statements guaranteed to print .true. (meaning > that the c%kind and c%len are of default kind) or not? > > For KIND parameters, although I can't find it explicitly stated, > I see fairly strong evidence that all intrinsic kind parameters > are intended to be default integers. This evidence is in the > intrinsic functions. The KIND intrinsic function and all the > selected_*_kind functions are specified to return default > integers, which would make for some strangeness if the kind > parameters were not default integer, in particular if the KIND > intrinsic could not return the kind of its argument because that > kind could not be represented in a default integer. > > There also seems no obvious benefit to having the kind of the > intrinsic kind parameters be anything other than default. In > practice, the number of supported values for kind is small and > would have no trouble being represented in a default integer; > large arrays of kind values are rare, so there isn't much > benefit in using representations smaller than default. > > For character length, I see no similar evidence. Indeed, the > LEN intrinsic seems to suggest that lengths might be other than > default integer. I believe that there was clear intent to > facilitate (but not require) support for character lengths > longer than could be expressed by a default integer. > > In most contexts, it doesn't directly matter what the kind of > length is. Parameter specifications in type-specs don't have to > match in kind. So the user could specify and do arithmetic on > lengths using whatever kind was appropriate for the anticipated > problem sizes. The limit on maximum character length is > processor-dependent anyway and is not necessarily the same > as HUGE(whatever) (though it is a bit hard to imagine how it > could usefully be larger). > > The only context in which I can see that might matter is in a > type parameter inquiry (6.1.3). We don't appear to have defined > the kind of a type parameter inquiry. Although we didn't say, I > am assuming that a type parameter inquiry ought to "return" the > kind of the type parameter it is inquiring about. Otherwise, > there would be no way to inquire about the type parameter values > of some derived type variables (if the values didn't fit in a > default integer). We probably ought to explicitly say, though. > > ANSWER: > > Q1. The kind parameters of all the intrinsic types are of > default integer kind. The kind parameter of the intrinsic > character length parameter is processor-dependent. > > The support for this answer is as described in the question. > Edits are provided to make this answer explicit. > > Q2. The kind parameter of a type inquiry is the same as that of > the type parameter inquired about. See page 123, lines 35-36. > > Q3. The first write statement is guaranteed to print a .true. value; > it is processor dependent whether the second one prints a .true. > or .false. value. > > EDITS: > > All edits apply to 04-007. > > At [36:14], [37:30], [39:15], [40:14], and [44:2], insert the > following sentence before "The kind": > The kind type parameter is of type default integer. > > At [40:10], before "its", insert "its kind is processor-dependent > and". > > SUBMITTED BY: Richard Maine > > HISTORY: 04-408 m170 F03/0020 Submitted > 04-408r1 m170 Passed by J3 meeting > 05-146 m171 Passed J3 letter ballot #10 > > ---------------------------------------------------------------------- > > NUMBER: F03/0023 > TITLE: IEEE_SET/GET_UNDERFLOW_MODE > KEYWORDS: IEEE, underflow mode > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > Is it allowed for the argument of IEEE_SET_UNDERFLOW_MODE or > IEEE_GET_UNDERFLOW_MODE to be an array? > > There appears to be no restriction against arrays in these > procedures. For IEEE_SET_UNDERFLOW_MODE, it is ill-defined > what an array would mean. The wording implies a scalar, in > that it talks about being true or false, but the restriction > to scalars is not explicit. For IEEE_GET_UNDERFLOW_MODE, it > could be defined, but seems a little silly and nonparallel. > > The similar procedures for rounding mode do explicitly > specify that their arguments are scalar. > > ANSWER: > > No, arrays are not allowed for these arguments. Edits are provided > to correct this error. > > EDITS: > > [374:21] Add "scalar and" after "shall be" > [380:13] Add "scalar and" after "shall be" > > SUBMITTED BY: Richard Maine > > HISTORY: 04-420 m170 F03/0023 Submitted - Passed by J3 meeting > 05-146 m171 Passed J3 letter ballot #10 > > ---------------------------------------------------------------------- > > NUMBER: F03/0025 > TITLE: Abstract types in CLASS IS type guard statements > KEYWORDS: ABSTRACT, CLASS IS, type guard, SELECT TYPE > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > Consider the following program: > > PROGRAM foo > > TYPE, ABSTRACT :: base > INTEGER i > END TYPE > TYPE, EXTENDS(base) :: child > INTEGER j > END TYPE > CLASS(*), POINTER :: x > TYPE(child), TARGET :: c1 > > x => c1 > SELECT TYPE (x) > CLASS IS (base) > PRINT *, 'Class is base' > CLASS DEFAULT > PRINT *, 'Class is not base' > END SELECT > > END > > Constraint C401 seems to prohibit the abstract type "base" from > appearing in a CLASS IS type guard statement, thus prohibiting this > program. There seems to be no reason to prohibit this, and allowing > it seems to be useful in some situations. > > Was this program intended to be standard-conforming? > > ANSWER: > > Yes, this program was intended to be standard-conforming. Edits are > provided to correct this oversight. > > EDITS: > > All edits refer to 04-007. > [162:17] Change "" to "". > [162:19] After "", insert "or ". > [162:20] After "", insert "or ". > [162:21] After "", insert "or ". > > SUBMITTED BY: Rob James > > HISTORY: 04-411 m170 F03/0025 Submitted > 04-411r1 m170 Passed by J3 meeting > 05-146 m171 Passed J3 letter ballot #10 > > ---------------------------------------------------------------------- > > NUMBER: F03/0026 > TITLE: Intrinsic types in CLASS IS type guard statements > KEYWORDS: CLASS IS, type guard, SELECT TYPE, intrinsic type > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > Consider the following program: > > PROGRAM foo > > CLASS(*), POINTER :: x > INTEGER, TARGET :: i > > x => i > SELECT TYPE (x) > CLASS IS (INTEGER) > PRINT *, 'How can INTEGER be a class?' > END SELECT > > END > > The description of a CLASS IS type guard statement refers to an > extension of the type specified. This makes no sense for > nonextensible types. C815 disallows all nonextensible derived types, > but nothing disallows intrinsic types, which are also nonextensible. > > Was this program intended to be standard-conforming? > > ANSWER: > > No, this program was not intended to be standard-conforming. Edits > are supplied to correct this oversight. > > EDITS: > > All edits refer to 04-007. Note that these edits are the same as the > edits proposed for F03/0025. > > [162:17] Change "" to "". > [162:19] After "", insert "or ". > [162:20] After "", insert "or ". > [162:21] After "", insert "or ". > > SUBMITTED BY: Rob James > > HISTORY: 04-412 m170 F03/0026 Submitted > 04-412r1 m170 Passed by J3 meeting > 05-146 m171 Passed J3 letter ballot #10 > > ---------------------------------------------------------------------- > > NUMBER: F03/0027 > TITLE: Assumed character length in type guard statements > KEYWORDS: CHARACTER, assumed length, type guard, SELECT TYPE > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > Consider the following program: > > PROGRAM foo > CHARACTER, TARGET :: c > CLASS(*), POINTER :: p > > p => c > SELECT TYPE (p) > TYPE IS (CHARACTER(*)) > PRINT *, 'Character of length ', LEN(p) > END SELECT > END > > Constraint C814 says that, in a type guard statement, the > shall specify that each length type parameter is assumed. > > Constraint C416 does not list a type guard statement as a context in > which "*" can be used as a length type parameter for a character. > > Was this program intended to be standard-conforming? > > > ANSWER: > > Yes, this program was intended to be standard-conforming. Edits are > supplied to correct this oversight. > > > EDITS: > > All edits refer to 04-007. > > [41:9] Remove "or". > [41:9+] Add a new list item: > "(3.5) in the of a type guard statement (8.1.5), > or" > [41:33+] Add a new list item: > "(3.5) If used in the of a type guard statement, > the associating entity assumes its length from the selector." > > > SUBMITTED BY: Rob James > > HISTORY: 04-413 m170 F03/0027 Submitted > 04-413r1 m170 Passed by J3 meeting > 05-146 m171 Passed J3 letter ballot #10 > > ---------------------------------------------------------------------- > > NUMBER: F03/0028 > TITLE: Commas in complex namelist output > KEYWORDS: Namelist, complex formatting, comma, semicolon > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > The 7th paragraph in 10.9.2 for list directed output says: > > "Complex constants are enclosed in parentheses with a > separator between the real and imaginary parts, each > produced as defined above for real constants. The separator > is a comma if the decimal edit mode is POINT; it is a > semicolon if the decimal edit mode is COMMA." > > There are similar words in most other places where complex > formatting is described. > > The second paragraph of 10.10.1.3 Namelist group object list > items says: > > "When the next effective item is of type complex, the input > form of the input value consists of a left parenthesis > followed by an ordered pair of numeric input fields > separated by a comma and followed by a right parenthesis. " > > Other places correctly describe namelist complex output as > having a separator, either a comma or a semicolon, depending > on the decimal edit mode. > > Should the namelist version be reworded to say "comma or > semicolon"? > > ANSWER: > > Yes. Edits are supplied to correct this oversight. > In addition, a similar issue exists for list directed input of > undelimited character values and namelist output of character > values. > > EDITS: > > All edits refer to 04-007. > > [240:13] Replace "comma" with "comma (if the decimal edit mode is > POINT), semicolon (if the decimal edit mode is COMMA)" > > [244:29] Replace "comma" with "separator". > [244:30] Before "The first", add the following sentence: > The separator is a comma if the decimal edit mode is > POINT; it is a semicolon if the decimal edit mode is > COMMA. > [244:32] Replace "comma" with "separator". > [244:33] Replace "comma" with "separator". > > [245:4] after "comma," insert " semicolon," > > SUBMITTED BY: Dick Hendrickson > > HISTORY: 04-409 m170 F03/0028 Submitted > 04-409r1 m170 Passed by J3 meeting > 05-146 m171 Failed interp letter ballot #10 > 05-164 m171 Passed by J3 meeting > 05-170 m172 Failed J3 letter ballot #11 > 05-257 m173 Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > > NUMBER: F03/0029 > TITLE: Negative zero and intrinsic functions > KEYWORDS: Negative zero, IEEE, intrinsic functions > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > 4.4.2 states > "Processors that distinguish between positive and negative zeros > shall treat them as equivalent ... as actual arguments to intrinsic > procedures other than those for which it is explicitly specified > that negative zero is distinguished" > > Q1. Does this mean that TRANSFER(-0.0,42) is required to give the same > answer as TRANSFER(+0.0,42)? The definition of TRANSFER has no > explicit mention of negative zero. > > Q2. Does this mean that MERGE(+0.0,-0.0,flag) always returns +0.0? > > Q3. Does this mean that SPREAD(-0.0,2) has the value [+0.0,+0.0] > instead of [-0.0,-0.0]? > > Q4. Does this mean that RESHAPE([-0.0],[1]) has the value [+0.0] > instead of [-0.0]? > > Q5. Does this mean that SET_EXPONENT(-0.0,10) is +0.0 not -0.0? > > Q6. Does this mean that if a REAL variable X has a negative zero > value, REAL(x,...) has a positive zero value? > > Q7. Does this mean that CMPLX(0,-0.0) has the value (+0.0,+0.0) > instead of (+0.0,-0.0)? > > Q8. Does this mean that if a complex variable C has a negative zero > imaginary part, that AIMAG(C) returns +0.0 instead of -0.0? > > Q9. In any other intrinsic function, if the definition of the > intrinsic would imply a different result for negative zero than > for positive zero, does this mean that the function returns the > positive zero answer for a negative zero argument? > > ANSWER: > > Q1. No. The definition of TRANSFER explicitly states that its result > has the same physical representation as its first argument. This > would not be possible if "equivalent" meant that the exact same > result had to be produced. > > Q2. No, this would contradict the definition of MERGE. > > Q3. No. SPREAD "replicates" its argument, which means that the value > of each copy is the same as the original, not just compare equal. > As with TRANSFER, this would not be possible with the suggested > interpretation of the text in 4.4.2. > > Q4+. No. As with the previous questions, this would require an > overly strict interpretation of the term "equivalent", > contradicting the clear intent of the function in question. > > DISCUSSION: > > The term "equivalent" in the quoted text in 4.4.2 refers to the > concept of mathematical equivalence, not physical or computational > equivalence. A clarifying edit is supplied. > > EDITS: > > [38:2] Before "equivalent" insert "mathematically". > > SUBMITTED BY: Malcolm Cohen > > HISTORY: 04-422 m170 F03/0029 Submitted - Passed by J3 meeting > 05-146 m171 Passed J3 letter ballot #10 > > ---------------------------------------------------------------------- > > NUMBER: F03/0045 > TITLE: Finalization and assumed-size arguments with INTENT(OUT) > KEYWORDS: finalization, INTENT(OUT), assumed size, dummy argument > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > Consider the following program: > > MODULE m > TYPE t > INTEGER :: i > CONTAINS > FINAL :: finalizeT > END TYPE > CONTAINS > ELEMENTAL SUBROUTINE finalizeT(f) > TYPE(t), INTENT(INOUT) :: f > f%i = 10 > END SUBROUTINE > END MODULE > > SUBROUTINE xyz (d) > USE m > TYPE(t), INTENT(OUT) :: d(*) > END SUBROUTINE > > PROGRAM foo > USE m > EXTERNAL xyz > TYPE(t) :: a(10) = t(5) > CALL xyz(a(2)) > END PROGRAM > > 4.5.5.2 of Fortran 2003 states: > When a procedure is invoked, a nonpointer, nonallocatable object > that is an actual argument associated with an INTENT(OUT) dummy > argument is finalized. > > For assumed-size arguments, this situation is similar to that of > default initialization with INTENT(OUT). Default initialization is > prohibited for INTENT(OUT), assumed-size dummy arguments by C544. A > similar restriction on finalization may have been overlooked. > > Was this program intended to be standard-conforming? > > ANSWER: > > No, this program was not intended to be standard-conforming. An edit > is supplied to correct this oversight. > > DISCUSSION: > > The unstated philosophy of assumed-size arrays in the standard is that > no action is allowed on an assumed-size array which would need to be > applied elementally to the whole array. That is why no whole array > assignment is allowed, for example. > > In accordance with this philosophy, > (1) types with ultimate allocatable components also need to be > excluded from being INTENT(OUT) assumed-size, as procedure > invocation in this case requires deallocation of all the > allocated components. > > (2) polymorphic INTENT(OUT) assumed-size arrays should also be > excluded, as they might have finalisation, default initialisation > or allocatable components. > > This interp subsumes Fortran 2003 interp #0060. > > EDITS: > > All edits refer to 04-007. > > [80:9] Before "of a type", insert > "polymorphic, of a finalizable type, of a type with an > ultimate allocatable component, or". > > SUBMITTED BY: Rob James > > HISTORY: 05-136 m171 F03/0045 Submitted, passed by J3 meeting > 05-170 m172 Passed J3 letter ballot #11 > N1622 m172 Failed WG5 ballot N1629 > 05-256 m173 Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > > NUMBER: F03/0056 > TITLE: Null input values and list-directed UDDTIO > KEYWORDS: null value, UDDTIO > DEFECT TYPE: Interpretation > STATUS: Passed by J3 letter ballot > > QUESTION: > > Consider the following program: > > MODULE m > PRIVATE > TYPE, PUBLIC :: t > INTEGER i > INTEGER j > CONTAINS > PROCEDURE, PRIVATE :: readFormatted => readFormattedT > GENERIC :: READ(FORMATTED) => readFormatted > END TYPE > CONTAINS > SUBROUTINE readformattedT(dtv, unit, iotype, v_list, iostat, iomsg) > CLASS(t), INTENT(INOUT) :: dtv > INTEGER, INTENT(IN) :: unit > CHARACTER(*), INTENT(IN) :: iotype > INTEGER, INTENT(IN) :: v_list(:) > INTEGER, INTENT(OUT) :: iostat > CHARACTER(*), INTENT(INOUT) :: iomsg > READ (unit, *) dtv%i > READ (unit, *) dtv%j > END SUBROUTINE > END MODULE > > PROGRAM p > USE m > INTEGER i > TYPE(t) x, y, z > x%i = 10 > x%j = 15 > y%i = 20 > y%j = 25 > z%i = 30 > z%j = 35 > i = 100 > READ (*,*) x, y, z, i > PRINT *, x, y, z, i > END PROGRAM > > The following is given as input to this program: > > 1044 2167 3977 / > 1 2 3 > > > 10.9.1.1 of Fortran 2003 (Null values) states: > > A slash encountered as a value separator during execution of a > list-directed input statement causes termination of execution of > that input statement after the assignment of the previous value. > > If a child data transfer statement encounters a slash as a value > separator, it is unclear whether this statement applies to just the > child statement, or to the parent data transfer statement as well. > The significance for any subsequent child statement is also unclear. > > What is the behaviour of this program when it is given the specified > input? > > > ANSWER: > > When a child data transfer statement encounters a slash as a value > separator, only that data transfer statement encounters the slash. > None of its parent data transfer statements encounters the slash. > Only the data transfer statement that encounters the slash is > terminated. > > The program above should print the following: > 1044.2167.3977.25.1.2.3 > where "." represents a value separator. > > > EDITS: > > None. > > > SUBMITTED BY: Rob James > > HISTORY: 05-171 m172 F03/0056 Submitted > 05-218 m173 Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > > NUMBER: F03/0057 > TITLE: Namelist I/O and UDDTIO > KEYWORDS: namelist, UDDTIO > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > Can namelist I/O ever invoke a user-defined derived-type I/O > procedure? > > 10.10.1.2 of Fortran 2003 (Namelist input values) implies that > namelist input cannot invoke a user-defined derived-type I/O > procedure. It says that, for a derived-type variable, "the effect is > as if the variable represented were expanded into a sequence of scalar > list items of intrinsic data types", which would preclude any > derived-type I/O. > > However, the same sentence says that this is done "in the same way > that formatted input/output list items are expanded (9.5.2)", which > would result in some effective list items of derived type. > > 9.5.3.6 and 9.5.3.7.2 also imply that a user-defined derived-type I/O > procedure could be invoked for a namelist group object. > > > ANSWER: > > Yes, namelist I/O can invoke a user-defined derived-type I/O > procedure. Edits are provided to correct this problem. > > > EDITS: > > All edits refer to 04-007. > > [244:8] Remove "of intrinsic data types". > > [244:10] Remove "intrinsic". > > > SUBMITTED BY: Rob James > > HISTORY: 05-172 m172 F03/0057 Submitted > 05-219 m173 Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > > NUMBER: F03/0058 > TITLE: Recursive namelist output > KEYWORDS: UDDTIO, namelist, output > DEFECT TYPE: Interpretation > STATUS: Passed by J3 letter ballot > > QUESTION: > > Consider the following program: > > MODULE mod > PRIVATE > TYPE, PUBLIC :: node > INTEGER :: value = 0 > CONTAINS > PROCEDURE, PRIVATE :: nodeFormattedWrite => writeroutine > GENERIC :: WRITE(FORMATTED) => nodeFormattedWrite > END TYPE > CONTAINS > SUBROUTINE writeroutine(dtv, unit, iotype, vlist, iostat, iomsg) > CLASS(node), INTENT(IN) :: dtv > INTEGER, INTENT(IN) :: unit > CHARACTER(LEN=*), INTENT(IN) :: iotype > INTEGER, INTENT(IN) :: vlist(:) > INTEGER, INTENT(OUT) :: iostat > CHARACTER(LEN=*), INTENT(INOUT) :: iomsg > > REAL a > NAMELIST /inner/ a > a = 4.0 > WRITE(unit, NML=inner) > END SUBROUTINE > END MODULE > > PROGRAM foo > USE mod > TYPE(node) :: a(2) > NAMELIST /outer/ a > a(1)%value = 1 > a(2)%value = 2 > WRITE(*, NML=outer) > END PROGRAM > > Is the following output standard-conforming for the above program? If > not, please give an example of standard-conforming output. > > &OUTER > A= &INNER > A=4.000000000 > /, &INNER > A=4.000000000 > / > / > > ANSWER: > > Yes > > EDITS: > > None > > SUBMITTED BY: Rob James > > HISTORY: 05-173 m172 F03/0058 Submitted > 05-220 m173 Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > > NUMBER: F03/0060 > TITLE: Default initialization of INTENT(OUT), assumed-size arrays > KEYWORDS: default initialization, INTENT(OUT), assumed size, polymorphism > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > Consider the following program: > > MODULE m > TYPE base > INTEGER I > END TYPE > TYPE, EXTENDS(base) :: child > INTEGER :: j = 5 > END TYPE > CONTAINS > SUBROUTINE sub(b) > CLASS(base), INTENT(OUT) :: b(*) > END SUBROUTINE > END MODULE > > PROGRAM foo > USE m > TYPE(child) :: c(3) > c%i = 12 > c%j = 47 > CALL sub(c) > PRINT *, c%j > END PROGRAM > > C544 prevents nonpolymorphic, INTENT(OUT), assumed-size arrays from > having default initialization. The polymorphic case, however, is not > checkable at compile time, so it cannot be a constraint. > > Was it intended that the dynamic type of an INTENT(OUT), assumed-size > array could have default initialization? If so, what does the above > program print? > > ANSWER: > > No, this was not intended. > > This interp is subsumed by Fortran 2003 interp # 45, > which contains edits making the above example non-conforming. > > EDITS: > > None > > SUBMITTED BY: Rob James > > HISTORY: 05-175 m172 F03/0060 Submitted > 05-222 m173 Edit provided > 05-222r1 m173 Subsumed by 0045 - Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > > NUMBER: F03/0061 > TITLE: Polymorphism and explicit-shape or assumed-size dummy arguments > KEYWORDS: polymorphism, assumed size, actual argument, dummy argument > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > Consider the following program: > > MODULE m > TYPE t1 > INTEGER :: i > END TYPE > CONTAINS > SUBROUTINE abc (b) > CLASS(t1) :: b(*) > EXTERNAL xyz > CALL xyz(b(2)) > END SUBROUTINE > END MODULE > > SUBROUTINE xyz(d) > USE m > TYPE(t1) :: d(2,3) > END SUBROUTINE > > PROGRAM foo > USE m > TYPE, EXTENDS(t1) :: t2 > INTEGER :: j > END TYPE > TYPE(t2) a(10) > CALL abc(a(2)) > END PROGRAM > > During the execution of "xyz", the dummy argument "d" is sequence > associated with the associated actual argument (which is true if "d" > has either explicit shape or assumed size). This implies that the > entity that is argument associated with "d" must be contiguous. > > The dummy argument "b" of the module subroutine "abc" is polymorphic, > and its dynamic type in this case is different than its declared type. > In this scoping unit, "xyz" has an implicit interface, so we know it > doesn't have any polymorphic arguments. So, the dummy argument of > "xyz" must be nonpolymorphic, and have the same declared type as the > actual argument (b(2)). > > This implies that we only want to pass the parent portion of b(2). > But the dummy argument of "xyz" may be an explicit-shape or > assumed-size array (in this case, it is an explicit-shape array). > > This means that we have to pass a contiguous array to "xyz". This > wouldn't be a problem if the dynamic type of "b" was the same as the > declared type, but in this case it is not. The parent portion of "b" > (from element 2 to the end of the array) must be copied into a > temporary array. > > The compiler cannot possibly know how big "b" is because it is an > assumed-size array, so it is impossible to make such a copy. > > Was this program intended to be standard-conforming? > > ANSWER: > > No, this program was not intended to be standard-conforming. Edits > are provided to correct this oversight. > > EDITS: > > All edits refer to 04-007. > > [270:27] Change "assumed-shape or pointer" to "assumed-shape, > pointer, or polymorphic". > > SUBMITTED BY: Rob James > > HISTORY: 05-176 m172 F03/0061 Submitted > 05-223 m173 Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > > NUMBER: F03/0062 > TITLE: Finalization of array constructors > KEYWORDS: Finalization, array constructor > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > Consider the following program: > > MODULE m > TYPE t > INTEGER i > CONTAINS > FINAL :: finalizeT > END TYPE > CONTAINS > SUBROUTINE finalizeT(obj) > TYPE(t) :: obj(:) > PRINT *, 'Finalizing a rank-1 array of type t' > END SUBROUTINE > END MODULE > > PROGRAM foo > USE m > TYPE(t) :: a > a%i = 5 > PRINT *, (/ (a, i=1,5) /) > END PROGRAM > > If the PRINT statement in the main program was printing a function > result or a structure constructor, rather than an array constructor, > it is clear that the object should be finalized after that PRINT > statement. > > However, for array constructors, this does not appear to be the case. > In the main program above, should the entity created by the array > constructor be finalized after execution of the PRINT statement? > > ANSWER: > > Yes, the array constructor should be finalized. Edits are provided to > correct this oversight. > > EDITS: > > This edit refers to 04-007. > [59:27] Replace both occurrences of "structure" with "structure > or array". > > This edit refers to the edit introduced by interpretation F03/0007. > Replace the first occurrence of "structure" with "structure > or array". > > SUBMITTED BY: Rob James > > HISTORY: 05-177 m172 F03/0062 Submitted > 05-224 m173 Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > NUMBER: F03/0063 > TITLE: Procedure pointers in BLOCK DATA program units > KEYWORDS: Procedure pointer, common block, block data > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > It is clear that procedure pointers are permitted in common blocks. > However, due to the restrictions on BLOCK DATA program units, it seems > that such a common block can not appear in a BLOCK DATA program unit. > > Was it intended that common blocks containing procedure pointers could > be initialized in a BLOCK DATA program unit? > > ANSWER: > > Yes, it was intended that common blocks containing procedure pointers > could be initialized in a BLOCK DATA program unit. Edits are provided > to correct this oversight. > > EDITS: > > All edits refer to 04-007. > > [253:12] After "derived-type definitions", insert > ", abstract interface blocks,". > > [253:14] Before "and type declaration", insert > "procedure declaration statements,". > > [254:3] After "specifiers", insert > "if it declares a data object". > > [254:3] Append a new sentence: > A procedure declaration statement shall not declare an > external procedure. > > SUBMITTED BY: Rob James > > HISTORY: 05-178 m172 F03/0063 Submitted > 05-225 m173 Passed by J3 meeting > 06-133r1 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > NUMBER: F03/0066 > TITLE: Precision of operation > KEYWORDS: precision, operation > DEFECT TYPE: Interpretation > STATUS: Passed by J3 letter ballot > > QUESTION: > > Given > REAL X > X = ... some value ... > IF( (X+3.0) .EQ. 3.0 )... > may the X+3.0 be computed with more range and/or precision than that > of REAL? In other words, is PRECISION(X) .EQ. PRECISION(X+3.0) always > true; or is PRECISION(X) .LT. PRECISION(X+3.0) sometimes true? > > References are to J3/04-007. > > 2.4.1.1 Intrinsic type has "The kind type parameter indicates ... the > decimal precision and exponent range for the real and complex types, > ..." > > 7.1.4.2 Type, type parameters, and shape of the result of an operation > has in (4) "For an expression x1 op x2 where op is a numeric intrinsic > binary operator with both operands of the same type and kind type > parameters, ..., the kind type parameter of the expression is > identical to that of each operand." > > Since X and 3.0 are the same type and have the same kind type > parameters, 7.1.4.2 (4) appears to require the X+3.0 have just the > range and precision of REAL; no more, no less (otherwise, the > precision is not identical). But, several members of the J3 email > list have said that the "+" may be done with more precision; using > either 1.4(6) or 7.1.8.3 as the reason. > > Perhaps something alone the lines of "The values of floating operands > and of the results of floating expressions may be represented in > greater precision and range than that required by the kind type > parameter; the kind type parameter is not changed thereby." should be > added to 7.1.4.2(4). > > QUESTION: > > Is PRECISION(X) .EQ. PRECISION(X+3.0) always true? > > ANSWER: > > Yes, that is the definition of PRECISION. The PRECISION intrinsic has > nothing to do with the precision in which the computation X+3.0 is > computed. 7.1.4.2 (4) only describes the precision of the end result > of the computation. > > The weasel words in 1.4 (6) allow the processor to compute this expression > in higher precision than REAL. > > EDITS: > > None > > SUBMITTED BY: Fred Tydeman > > HISTORY: 05-193 m173 F03/0066 Submitted > 05-193r1 m173 Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > > NUMBER: F03/0067 > TITLE: Accuracy of conversion of real literal constants > KEYWORDS: conversion, accuracy > DEFECT TYPE: Interpretation > STATUS: Passed by J3 letter ballot > > QUESTION: > > The following is independent of IEEE-754. > > Fortran 2003 10.6.1.2.6 covers conversions between "decimal values" > and "internal values" and has some strong requirements. > > Are there equivalent requirements on accuracy for conversions of real > literal constants? Sections 4.1.2 and 4.4.2 seems like the places to > find them (if they exist). > > What rounding mode is used for conversions of real literal constants? > Is the same rounding mode used for all such conversions? > > The following four questions are about positive values, but the same > would apply to negative values. > > Must all "decimal values" in the range smallest non-zero finite > internal value (which could be a denormal) to largest finite internal > value, e.g. 0.1, be converted? > > Must all "decimal values" in the range zero to smallest non-zero > finite internal value, e.g. 1.0e-999999999, be converted? > > Must all "decimal values" larger than the largest finite internal > value, e.g. 9.9e+99999999999, be converted if infinity is an internal > value? What does nearest rounding mean for these cases? > > What requirements exist for "decimal values" larger than the largest > finite internal value if infinity is not an internal value? > > ANSWER: > > There are no requirements on accuracy for conversions of real literal > constants. > > The standard does not specify the rounding mode used for conversions > of real literal constants, nor does it require the same rounding mode > to be used for all conversions. > > Whether all decimal values in any range can be converted is not > standardized. > > There are no requirements for "decimal values" larger than the largest > finite internal value whether infinity is an internal value or not. > > EDITS: > > None > > SUBMITTED BY: Fred Tydeman > > HISTORY: 05-206 m173 F03/0067 Submitted > 05-206r1 m173 Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > > NUMBER: F03/0068 > TITLE: First character of namelist output records > KEYWORDS: namelist, output, UDDTIO > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > The last sentence of 10.10.2.2 of Fortran 2003 states: > Except for continuation of delimited character sequences, each > output record begins with a blank character. > > If a namelist output statement causes a user-defined derived-type > output procedure to be called, was it intended to be standard- > conforming for that procedure to create a new record (perhaps by using > the slash edit descriptor) that does not begin with a blank character? > > ANSWER: > > Yes, this situation was intended to be standard-conforming. Explicit formatting > in user-defined derived-type output is not required to output a leading blank > in this case. An edit is provided to correct this oversight. > > EDITS: > > All edits refer to 04-007. > > [247:33] Before "continuation", insert "new records created by > explicit formatting within a user-defined derived-type > output procedure or by". > > SUBMITTED BY: Rob James > > HISTORY: 05-227 m173 F03/0068 Submitted > 05-227r1 m173 Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > > NUMBER: F03/0069 > TITLE: Procedure pointers in defined assignment > KEYWORDS: procedure pointer, defined assignment > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > In 12.3.2.1.1 of Fortran 2003, at [262:8-9], the following is stated > about the dummy arguments of a function that defines an operation: > The dummy arguments shall be nonoptional dummy data objects and > shall be specified with INTENT (IN). > > This clearly states that a dummy argument of such a function cannot be > a procedure pointer. The same is not stated for the dummy arguments > of a subroutine that defines assignment. > > Was it intended that procedure pointers should be allowed in defined > assignment, but not in defined operations? > > ANSWER: > > No. It was not intended that procedure pointers should be allowed in > either defined assignment or defined operations. An edit is provided > to correct this oversight. > > EDITS: > > All edits refer to 04-007. > > [263:6] Replace "Each argument shall be nonoptional." with > "The dummy arguments shall be nonoptional dummy data objects." > > SUBMITTED BY: Rob James > > HISTORY: 05-228 m173 F03/0069 Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot > > ---------------------------------------------------------------------- > > NUMBER: F03/0070 > TITLE: Can child I/O statements be advancing I/O statements? > KEYWORDS: UDDTIO, ADVANCE= > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > [175:30-31] of Fortran 2003 states: > An advancing input/output statement always positions a record file > after the last record read or written, unless there is an error > condition. > > Since a child I/O statement does not position a file after the last > Record [194:19][199:8-9], this implies that a child I/O statement cannot > be an advancing I/O statement. > > [189:6-9] of Fortran 2003 states: > The ADVANCE= specifier determines whether advancing input/output > occurs for this input/output statement. If YES is specified, > advancing input/output occurs. If NO is specified, nonadvancing > input/output occurs (9.2.3.1). If this specifier is omitted from > an input/output statement that allows the specifier, the default > value is YES. > > This clearly states that any data transfer statement is an advancing > I/O statement if the value 'NO' is not specified for the ADVANCE= > specifier. > > These two statements seem to contradict each other. > > QUESTION: > > If a child I/O statement does not have an ADVANCE= specifier with the > value 'NO', is it an advancing I/O statement? > > DISCUSSION: > > The answer to this question affects the value for the IOSTAT variable > for child READ statements in some situations. For example, in the > following program, the value of "stat1" should be equal to IOSTAT_EOF > if the child READ statement is advancing, but it should be equal to > IOSTAT_EOR if the statement is nonadvancing. > > MODULE m > TYPE t > CHARACTER(2) :: x(2) > CONTAINS > PROCEDURE :: readT > GENERIC :: READ(FORMATTED) => readT > END TYPE > CONTAINS > SUBROUTINE readT(dtv, unit, iotype, v_list, iostat, iomsg) > CLASS(t), INTENT(INOUT) :: dtv > INTEGER, INTENT(IN) :: unit > CHARACTER(*), INTENT(IN) :: iotype > INTEGER, INTENT(IN) :: v_list(:) > INTEGER, INTENT(OUT) :: iostat > CHARACTER(*), INTENT(INOUT) :: iomsg > READ (unit, '(2a2)', IOSTAT=iostat) dtv%x > END SUBROUTINE > END MODULE > > PROGRAM p > USE m > USE, INTRINSIC :: ISO_FORTRAN_ENV > TYPE(t) t1 > CHARACTER(3) :: c = '123' > INTEGER stat1 > READ (c, *, IOSTAT=stat1) t1 > PRINT *, (stat1 == IOSTAT_EOR), (stat1 == IOSTAT_EOF) > END PROGRAM > > ANSWER: > > No, such a child I/O statement is not advancing. Edits are provided > to correct this inconsistency. > > EDITS: > > All edits refer to 04-007. > > [189:7] After "this" insert " nonchild". > > [189:9] Replace "from an" with "from a nonchild". > > [189:9] After "YES." Insert > " A child input/output statement is a nonadvancing input/output > statement, and any ADVANCE= specifier is ignored." > > SUBMITTED BY: Rob James > > HISTORY: 05-229 m173 F03/0070 Submitted > 05-229r1 m173 Passed by J3 meeting > 06-133 m175 Passed by J3 letter ballot - typos fixed > > ---------------------------------------------------------------------- > > NUMBER: F03/0072 > TITLE: Default initialization for "automatic" components > KEYWORDS: Parameterized Derived Type, Default Initialization > DEFECT TYPE: Erratum > STATUS: Passed by J3 letter ballot > > QUESTION: > > Consider > TYPE t(len) > INTEGER,LEN :: len > CHARACTER(len) :: cvalue = "xyz" > END TYPE > > SUBROUTINE s(n) > TYPE(t(n)) x > ... > > TYPE t2(len2) > TYPE(t(len2)) :: tvalue = t(10,"fred nurke") > END TYPE > > SUBROUTINE s2(n) > TYPE(t(n)) :: y > ... > > The type definition for T appears to conform to the standard; it > allows an "automatic" component to be default initialized. However, > the declaration of the local variable X in subroutine S will > initialize the component differently depending on the value of N, for > example, giving the CVALUE component the value "", "x", "xy", "xyz", > "xyz " for N being 0, 1, 2, 3, 4 respectively. > > Q1. Was it intended that "automatic" components can be > default-initialized? > > If the answer is "Yes", the type definition for T2 also appears to > conform to the standard. However, the declaration of Y in S2 will not > work if N has any value other than 10 at run time. This is > surprising; there appears to be no other situation where the runtime > value of a length type parameter can render a declaration invalid. > Is this situation intentional? > > ANSWER: > > Q1. No, this was not intended. An edit is supplied to fix this. > > Q2. Not applicable. > > EDITS: > > In 4.5.3 Components, immediately before R445 > , insert a new constraint: [50:40+] > "C447a (R440) If appears, every type > parameter and array bound of the component shall be an > initialization expression." > > SUBMITTED BY: Malcolm Cohen > > HISTORY: 05-285 m174 F03/0072 Submitted > 05-285r1 m174 Revised edit > 06-133 m175 Passed by J3 letter ballot