From jkr@jkr.cc.rl.ac.uk Wed Jan 17 17:05:09 2001 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id RAA34370 for ; Wed, 17 Jan 2001 17:05:08 +0100 (CET) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id QAA18325 for ; Wed, 17 Jan 2001 16:05:07 GMT Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id QAA23763 for SC22WG5@dkuug.dk; Wed, 17 Jan 2001 16:06:45 GMT Date: Wed, 17 Jan 2001 16:06:45 GMT From: John Reid Message-Id: <200101171606.QAA23763@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: N1423: WG5 letter ballot on interpretations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" WG5 members, Please will you consider the appended interpretations by 23 March? Thanks, John. ............................. ISO/IEC JTC1/SC22/WG5 N1423 WG5 letter ballot on Fortran 95 interpretations John Reid, 17 January 2001 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. I have made minor corections to items 14, 15, 32, 73, as requested with YES ballots by J3 members. The following Fortran 95 interpretations are being balloted: Yes No Number Title --- --- 000014 Format of complex numbers in list-directed and namelist output --- --- 000015 Commas in list-directed output --- --- 000032 Is the TRANSFER function result undefined? --- --- 000073 Is padding allowed in storage sequences? --- --- 000075 Defined assignment and INTENT(IN) dummy arguments in PURE procedures --- --- F90/000197 Relationship of NEAREST and SPACING --- --- JP-12 Bounds of each dimension of an array pointer The text of these interpretetions is attached. Each interpretation starts with a row of "-"s. Please mark the above "yes" or "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 midnight Friday, 23 March 2001, in order to be counted. --------------------------------------------------------------------- NUMBER: 000014 TITLE: Format of complex numbers in list-directed and namelist output KEYWORDS: DEFECT TYPE: STATUS: J3 approved; ready for WG5 QUESTION: 1. The seventh paragraph of Section 10.8.2 of the Fortran 95 standard states that complex numbers must be written with no embedded blanks unless the complex constant is broken across two records. Some of the implementations I tested put a blank after the comma even when the entire constant fit in a single record. Is an implementation permitted to include a blank after the comma in a complex constant produced by list-directed output when the constant fits in a single record? 2. Is a blank permitted after the comma in a complex constant produced by namelist output when the constant fits in a single record? ANSWER: 1. No. Section 10.8.2 [178:2-3] states: "The only embedded blanks permitted within a complex constant are between the comma and the end of a record and one blank at the beginning of the next record." 2. No. Section 10.9.2.1 [182:40-41] states: "The only embedded blanks permitted within a complex constant are between the comma and the end of a record and one blank at the beginning of the next record." SUBMITTED BY: HISTORY: 97-165 m143 Submitted WG5/N1410 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by letter ballot --------------------------------------------------------------------- NUMBER: 000015 TITLE: Commas in list-directed output KEYWORDS: DEFECT TYPE: STATUS: J3 approved; ready for WG5 QUESTION: 5. The first paragraph of Section 10.8.2 of the Fortran 95 standard states: With the exception of adjacent nondelimited character constants, the values are separated by one or more blanks or by a comma optionally preceded by one or more blanks and optionally followed by one or more blanks. I have yet to find a Fortran implementation, other than my own, that satisfies this requirement. In particular, the statement PRINT *, 1, ',', 2 prints a comma immediately following the 1 on every implementation I tried. The comma was followed by zero, one, or two blanks in different implementations. 1. Is a separator required between a constant other than a nondelimited character constant and a following nondelimited character constant in list-directed output? 2. Is a separator required between a nondelimited character constant and a following constant that is not a nondelimited character constant? DISCUSSION: It is not clear in the question if the comma which is output is the optional separator or is the character constant from the list. ANSWER: 1. Yes. 2. Yes. A separator is required in both cases. The text quoted, which is at page 177:31-33, is quite explicit. The key word is "adjacent". SUBMITTED BY: HISTORY: 97-165 m143 Submitted WG5/N1410 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by letter ballot ---------------------------------------------------------------------- NUMBER: 000032 TITLE: Is the TRANSFER function result undefined? KEYWORDS: transfer function, undefined, processor dependent DEFECT TYPE: STATUS: J3 approved; ready for WG5 The result value section of the TRANSFER function says "...If the physical representation of the result is longer than that of SOURCE, the physical representation of the leading part is that of SOURCE and the remainder is undefined." ^^^^^^^^^^^^^^^^^^^^^^^^^^ and case (ii) gives an example of a transfer of 3 reals to 2 complexes with the imaginary part of the second complex being undefined. Where can you use this form of TRANSFER? There's a general prohibition about referencing undefined things. Doesn't that apply to expressions containing TRANSFER as well? Something like X = transfer (four_bytes,eight_bytes) or X = transfer(transfer(four_bytes,eight_bytes), four_bytes) reference the undefined part. Maybe in the latter case we could say that the "reference" in the outer transfer doesn't "require the value" of all of its argument. But that seems like an odd reading to me. We can't use it for functions like SIZE, because they only allow their argument to be undefined if it is a single variable name (13.8.5). The only thing I can think of is passing to a procedure argument that has no INTENT specified but that uses the defined part of the argument as if it were INTENT(IN). The intent can't be specified because INTENT(IN) arguments must be defined on entry. Question: Should the phrase be changed from "the remainder is undefined" to "the remainder is processor dependent"? DISCUSSSION: This is made more confusing by: "Any variable or function reference used as an operand shall be defined at the time the reference is executed." [97:1] The mention of function reference is confusing, because a function is not allowed to return without fully defining its result, viz "If the result variable is not a pointer, its value shall be defined by the function." [207:28] ANSWER: Yes, for the reasons given. Edits are provided. EDITS: Clause 13.14.110 Page 272, line 4. Change 'undefined' to 'processor dependent'. Page 272, line 17. Change 'undefined' to 'processor dependent'. SUBMITTED BY: Dick Hendrickson HISTORY: 98-183 Submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by letter ballot ---------------------------------------------------------------------- NUMBER: 000073 TITLE: Is padding allowed in storage sequences? KEYWORDS: alignment, padding, storage sequence DEFECT TYPE: STATUS: J3 approved; ready for WG5 QUESTION: 1. Is padding allowed in storage sequences? Consider the common block CHARACTER C INTEGER I COMMON /CBLK/ C, I 2. Is padding allowed between the variables C and I? Consider the sequence type TYPE T SEQUENCE CHARACTER C INTEGER I END TYPE 3. Is padding allowed between component C and component I? Discussion: A user recently complained that Sun f90 adds pad for alignment to sequence types and common blocks. He asserted that the Fortran standard forbids padding storage sequences. I have tested seven different implementations, and I found that all but one use padding in the examples given. The user based his assertion on the text of Section 14.6.3.1 of the Fortran 95 standard. He claimed the statements (7) A nonpointer scalar object of sequence type occupies a sequence of storage sequences corresponding to the sequence of its ultimate components and The order of the storage units in such a composite storage sequence is that of the individual storage units in each of the constituent storage sequences taken in succession, ignoring any zero-sized constituent sequences. made his case. I pointed out that where the standard intends to require storage units to be contiguous, it uses the word "contiguous". He was not satisfied by that answer. The user pointed out that the definition of the size of a storage sequence supports his assertion. He claimed that the size of the common block given above is one character storage unit plus one numeric storage unit, and that that is the size of the common block INTEGER J CHARACTER D COMMON /CBLK/ J,D which Sun f90 does not pad. While that arithmetic of sizes makes sense, I have been told informally by a committee member that that was not the intent of the committee. Note 5.33 lends support to his statement. I have been unable to find any for the first paragraph of Note 5.33 in the normative part of the standard. I suggest moving the first paragraph of Note 5.33 to the normative part of the standard. I tried to provide a definition of addition of sizes of different storage units that would imply the effect stated in Note 5.33, but I failed. ANSWER: 1. Yes. Padding between storage units is allowed unless those storage units are explicitly required to be contiguous in Section 14.6.3.1 or they are required to be contiguous in order to satisfy the storage association rules given in Sections 14.6.3.2 and 14.6.3.3. Note 5.33 (page 70) states: 'A common block is permitted to contain sequences of different storage units'. This is a consequence of the absence of any requirement on the types of the variables in a common block. It further states 'provided each scoping unit that accesses the common block specifies an identical sequence of storage units for the common block'. This is an informal rewording of the rules on common association which are found in sections 5.5.2.1 and 5.5.2.3, and the rules on storage association which are in 14.6.3. 5.5.2.1 and 5.5.2.3 do not prohibit padding between sequences of storage units, but any such padding is required to be consistent between scoping units. 2. Yes. 3. Yes. REFERENCES: ISO/IEC 1539-1:1997(E), Note 5.33 and Section 14.6.3. EDITS: None. SUBMITTED BY: Robert Corbett HISTORY: 99-190 m150 submitted (straw vote to allow padding 11-0-0) WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by letter ballot ---------------------------------------------------------------------- NUMBER: 000075 TITLE: Defined assignment and INTENT(IN) dummy arguments in PURE procedures KEYWORDS: INTENT(IN), PURE, defined assignment, dummy arguments DEFECT TYPE: STATUS: J3 approved; ready for WG5 QUESTION: Consider the following module: MODULE m TYPE t REAL,POINTER :: value END TYPE INTERFACE ASSIGNMENT(=) MODULE PROCEDURE t_asgn_t END INTERFACE CONTAINS PURE SUBROUTINE t_asgn_t(lhs,rhs) TYPE(t),INTENT(OUT) :: lhs TYPE(t),INTENT(IN) :: rhs ALLOCATE(lhs%value) lhs%value = rhs%value END SUBROUTINE PURE FUNCTION t_plus_t(a,b) TYPE(t) t_plus_t,a,b INTENT(IN) a,b t_plus_t = a !defined assignment !Alternative: CALL t_asgn_t(a,b) t_plus_t%value = t_plus_t%value + b%value END FUNCTION END According to F95 [212:33-45] "Constraint: In a pure subprogram any variable which ... is a dummy argument to a pure function ... shall not be used in the following contexts: ... (8) As the of an in which the is of a derived type if the derived type has a pointer component at any level of component selection; ..." Therefore it appears that the statement labelled "defined assignment" is not allowed. However, it is semantically equivalent to the commented-out statement in the following line, which would have been allowed. Clearly intrinsic assignment in that context must be disallowed as it implicitly does a pointer assignment which could be used to produce a side-effect, but the standard appears to rule out defined assignment as well (which if pure cannot cause any side-effect). Is this intentional? ANSWER: No. (8) should apply only to intrinsic assignment so the example is correct. EDIT: Clause 12.6. Penultimate line of page 212 [212:44]. Change to 'intrinsic assignment statement'. SUBMITTED BY: Malcolm Cohen HISTORY: 99-201 m150 submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by letter ballot ---------------------------------------------------------------------- NUMBER: F90/000197 TITLE: Relationship of NEAREST and SPACING KEYWORDS: NEAREST, SPACING, "machine representable" DEFECT TYPE: STATUS: J3 approved; ready for WG5 QUESTION: The example in the SPACING intrinsic function description states: SPACING(3.0) has the value 2**(-22) for reals whose model is as at the end of 13.7.1. The example in the NEAREST intrinsic function description states: NEAREST(3.0, 2.0) has the value 3 + 2**(-22) on a machine whose representation is that of the model at the end of 13.7.1. Must the delta computed by NEAREST (the 2**(-22) shown in the example) be the value SPACING would return if given the same (first) argument as passed to NEAREST? ANSWER: No. DISCUSSION: The result of NEAREST depends on the characteristics of machine numbers, whereas the result of SPACING depends on the characteristics of model numbers. If there are one or more machine numbers in between two adjacent model numbers, the results of SPACING and NEAREST will not be consistent with each other. EDIT(S): None. SUBMITTED BY: Larry Rolison HISTORY: 95-030 m132 submitted WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by letter ballot ---------------------------------------------------------------------- NUMBER: JP-12 TITLE: Bounds of each dimension of an array pointer KEYWORDS: DEFECT TYPE: STATUS: J3 approved; ready for WG5 QUESTION: JP-12) 5.1.2.4.3 (2) after R518 (Page 55 Line 41) states that: "(2) They are specified in a pointer assignment statement. ..." In this description, the term "pointer assignment statement" should be changed to "pointer assignment". Reason : The bounds of each dimension of an array pointer may be specified not only in a pointer assignment statement but also in a derived-type intrinsic assignment statement with a component of an array pointer. ANSWER: Agreed EDIT: [55:41] Delete "statement" and replace "in a" with "by". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Passed by letter ballot ----------------------------------------------------------------------