From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Mar 19 13:32:11 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 0D588356843; Mon, 19 Mar 2012 13:32:10 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-2-a-1.mail.uk.tiscali.com (mk-filter-2-a-1.mail.tiscali.co.uk [212.74.100.53]) by www.open-std.org (Postfix) with ESMTP id 2543C356822 for ; Mon, 19 Mar 2012 13:32:07 +0100 (CET) X-Trace: 740919897/mk-filter-2.mail.uk.tiscali.com/B2C/$b2c-THROTTLED/TalkTalk_Customer/2.97.124.206/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 2.97.124.206 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: XX/UNKNOWN X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Firefox/11.0 SeaMonkey/2.8 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgBACgmZ08CYXzO/2dsb2JhbAAMNrM9hh0BAQQnLBsKESwMCg8JAwIBAgFFBg0IAhfBWopOgwCDLgSOZoNLCYMuhVuKTYJmgVUH X-IronPort-AV: E=Sophos;i="4.73,611,1325462400"; d="txt'?scan'208";a="740919897" Received: from host-2-97-124-206.as13285.net (HELO [127.0.0.1]) ([2.97.124.206]) by smtp.tiscali.co.uk with ESMTP; 19 Mar 2012 12:32:04 +0000 Message-ID: <4F6727C2.1020802@stfc.ac.uk> Date: Mon, 19 Mar 2012 12:34:10 +0000 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: WG5 Subject: Vote on N1904 References: <20120312152923.857DB9DB112@www.open-std.org> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070003050001070204090306" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------070003050001070204090306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG5, The vote on N1904 has closed (see N1908) and the tentative ballot result is attached. Please let me know within 48 hours if I have overlooked your ballot or made any mistakes. While the ballot has failed, we are converging. The changes needed this time are not as extensive as last time. Bill Long hopes that he can lead the interop email group to agree a new draft within two weeks and I propose then to hold a 2-week WG5 ballot. Best wishes, John. --------------070003050001070204090306 Content-Type: text/plain; charset=windows-1252; name="N1910-1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1910-1.txt" ISO/IEC JTC1/SC22/WG5 N1910-1 Result of WG5 letter ballot on N1904 John Reid N1908 asked this question Please answer the following question "Is N1904 ready for forwarding to SC22 as the DTS?" in one of these ways. 1) Yes. 2) Yes, but I recommend the following changes. 3) No, for the following reasons. 4) Abstain. The numbers of answers in each category were: 0 for 1) Yes. 1 for 2) Yes, but I recommend the following changes (Bader) 5 for 3) No, for the following reasons. (Chen, Cohen, Long, Maclaren, Reid) 0 for 4) Abstain. The ballot has failed. Here are the responses in detail _______________________________________________________________________ Reinhold Bader 2) Yes, but I recommend the following changes. (references are to N1904, unless indicated otherwise. Edits to clause 9 have been omitted). (A) [p 9, Constraint C407a]: Based on the email discussion started by Tobias Burnus, I agree with John Reid's conclusion that INTENT(OUT) should be prohibited here. Edit: In C407a, before "POINTER", insert "INTENT(OUT)," (B) [p 10, para following C535b]: The complete paragraph appears to be redundant. Its first sentence is covered by 7.2, and the second sentence by the first sentence in 6.3. So either it should be removed, or turned into a NOTE. (C) [p 25, first sentence of Example 1] Replace "array to pass to" by "array which can be passed to". (D) [p 29, section 8.4, second bullet]: Change "C decriptor" to "C descriptor" (E) [p 29, NOTE 8.11]. The last sentence is perhaps a bit too vague. I suggest replacing it by "C programmers should note that modifying C descriptors in ways that are inconsistent with Fortran semantics, or referencing or defining data stored at addresses computed from the /base_addr/ member of a C descriptor that do not correspond to a subobject of the described Fortran object will cause undefined behaviour." (F) [p 29, section 8.5]. The last paragraph of this section seems to be misplaced. I suggest moving it to become para 2 of 8.3.5.1, in which case the text "functions described in 8.3.5" should be changed to "macro and functions described in this subclause", and a similar change should be done for the text "function defined in 8.3.5" later in the paragraph. (G) [p 30, NOTE 8.12] I suggest changing the NOTE's first sentence to "The following example illustrates how a C descriptor becomes undefined upon returning from a call to a C function." (H) Consider the Fortran type definition type :: fa integer(c_int), allocatable :: i(:) end type and the following interface interface subroutine fa_alloc(o_fa) BIND(C) type(fa), allocatable :: o_fa(:) end subroutine end interface for which an implementation in C is assumed, which performs allocation of the object via CFI_allocate. According to the rules given in 8.7, this appears to be standard-conforming; the descriptor on the C side would have a type member with value CFI_type_other. However, CFI_allocate in general would not have any knowledge on how to set up the type component o_fa%i (in particular if fa_alloc is invoked from C with an actual argument created inside C); this would appear to be a situation similar to that described in NOTE 5.4. The same argument applies for the POINTER attribute. I therefore suggest to add restrictions which prevent this situation from occurring. Required edits: [p 10] Change C516 to "C516 The ALLOCATABLE or POINTER attribute shall not be specified for a dummy argument of a procedure that has a /proc-language-binding-spec/ if it (a) is of a type with default-initialized components, or (b) is of a non-interoperable type that has type parameters, final procedures, type-bound procedures or components that have the ALLOCATABLE or POINTER attribute." [p 24, section 8.3.5.5] In the description of the type argument of CFI_establish, add "If it has the value CFI_type_other, /dv/ shall not be the descriptor for an object of a non-interoperable Fortran type that has type parameters, final procedures, type-bound procedures or components that have the ALLOCATABLE or POINTER attribute." (one could also forbid CFI_type_other altogether. This would prevent creating a descriptor whose base_addr points to an object of C union type. Perhaps an entry CFI_type_union with a negative value should be added to table 8.2?) (I) The argument of (H) may also be applied to the case of an INTENT(OUT) dummy. The last two paragraphs of 6.3 imply that in a C-to-C call it is the responsibility of the C programmer to perform deallocation for an ALLOCATABLE entity. However, in the case of CFI_type_other corresponding to a non-interoperable type with ALLOCATABLE type components there is no possibility for the C programmer to do type component deallocation. I suggest to disallow specifying INTENT(OUT) in this case. Edit: [8.7]: Add the restriction "If a dummy argument in an interoperable interface is of a non-interoperable type that is finalizable or has components with the ALLOCATABLE attribute, it shall not have the INTENT(OUT) attribute." (J) If finalizers are not considered a special case of type-bound procedures, explicitly adding them in at least some of the places where the term "type-bound procedures" appears in N1904 may be appropriate. The term occurs on pages 13, 20, 31, [36, 40]. (K) I am a bit surprised that it seems to be possible to have a CLASS(foo) :: a(:) assumed-shape dummy in an interoperable interface, while a polymorphic scalar appears to be prohibited. Was this intended? If not, an additional restriction is needed in 8.7, viz. "If a dummy argument in an interoperable interface is polymorphic, it shall be assumed-type." Alternatively, one could liberalize things by adding another item to the list of allowed dummies: ", or (e) the dummy argument is a polymorphic scalar that is not assumed- type, and corresponds to a formal parameter of the prototype that is a pointer to CFI_cdesc_t" (and remove the "or" at the end of (c)). I suspect the latter is more problematic, and therefore prefer the former; in particular C516 could not be a constraint if the latter is adopted (thanks to Tobias Burnus for pointing this out). _______________________________________________________________________ Daniel Chen: I vote 3) No, for the following reasons. a. There is an outstanding issue that the current TS allows TYPE(*) also be INTENT(OUT). As discussed in J3/WG5 mailing lists, this should be disallowed. b. Edit is needed for C1255 possibly other places to allow allocatable and pointer arguments. c. coarray dummy argument should be disallowed _______________________________________________________________________ Malcolm Cohen: No, for the following reasons. REASON: Too many technical and editorial problems remain in the document. Here are suggested edits to improve the document. Due to lack of time, this only has fixes for some problems noted in subclauses 8.3 to 8.6. 8.3.1 Summary of contents, p1 After "The \cf{ISO_Fortran_binding.h} heading file" change "contains the" to "shall contain" because this is a requirement (on the processor) not a statement of fact. Later, change "The contents of" to "The types, macros, and functions declared in" because it is physically impossible to use the "contents" of a header file to allocate or deallocate anything. 8.3.5.1p1 After "The" change "macro" to "macros" because there are several macros defined by ISO_Fortran_binding.h. After "and functions described in" change "this subclause" to "subclause 8.3" because "this subclause" is 8.3.5.1, and it contains no macro or function! 8.3.5.1p3 End the last sentence with a full stop. Maybe "as follows:" -> "as described in the following subclauses of 8.3.5." Or "The prototypes for these functions in \cf{ISO_Fortran_binding.h} shall be consistent with the specifications in subclause 8.3." because ungrammatical and not conforming to ISO guidelines. 8.4p1 There are no functions "specified here". Perhaps "specified by this Technical Specification"? If not, specify precisely which functions or which subclauses they lie in. 8.4, Note 8.11 [p29] Do we really have to say "C programmers should note"? In any case it is far too weakly worded (Reinhold's version does not really improve this), here is my suggestion: "A C function that modifies a C descriptor other than as permitted by this Technical Specification will cause undefined behaviour." BTW re Reinhold's version - pointer arithmetic beyond the limits of an object is already undefined behaviour in C, so I think we need not (and should not) say anything about that. 8.5p3, 1st bullet point, after "INTENT(IN)" change "argument" to "attribute". 8.5p4 I agree with Reinhold that this is out of place here, since it is not saying anything about "formal parameters". However his suggested wording changes would be incorrect. 8.6, NOTE 8.12, please change "ary" to "x". Having both "ary" and "array" in the same piece of code looks like the programmer is poor at spelling and makes it too easy to misunderstand any description. same note, final sentence is completely misleading. "ary" (please, "x") does not have the TARGET attribute and therefore any C pointer to a location inside of X becomes undefined whether ARRAY has the TARGET/ASYNCHRONOUS attribute or not. Perhaps you should make X into an array pointer and allocate it before the call or something, anyway the example is hopeless as is. _______________________________________________________________________ Bill Long: 3) No, for the following reasons. There are two technical problems with N1904: - Because INTENT(OUT) causes an argument to become undefined when the routine is called, it coexists poorly with TYPE(*). The combination of TYPE(*) and INTENT(OUT) should be disallowed. - A more obscure, but more serious problem, is that the text of C1255, while improved to allow OPTIONAL arguments, still requires that the variables in a BIND(C) call be interoperable objects. The test in 15.3.5 disallows the very things the TS is intended to allow (allocatable and pointer arguments). The requirement needs to be weakened to interoperable types (not objects) and then additional requirements to account for TYPE(*) arguments and coarray arguments. An email thread on the J3/WG5 lists proposed solutions for this, but the change is significant enough to justify another review (in my opinion). There are also more minor wording and typo fixes that were mentioned by others that should be fixed since a new draft will be required anyway. _______________________________________________________________________ Nick Maclaren: 3) No, for the following reasons: (A) Page 9, C407a and page 13 6.3 paragraph 3. Email discussions arising from Tobias Burnus's attempt at implementation indicate that there are still significant problems with this and actual arguments that have ALLOCATABLE or POINTER components, default-initialized components, final subroutines, and perhaps more. Components with polymorphic types may also be a problem, but I do not completely understand the existing constraints on those. These were considered during its design, but seem to have been underestimated. With hindsight, I feel that the specification of TYPE(*) is far too liberal. Note that the proposals to simply forbid INTENT(OUT) together with assumed-type exclude reasonable uses of INTENT(OUT) (e.g. for MPI receive buffers), but some constraint along those lines seems the best solution. The following is badly worded and may not be enough, but is put forward as a possibility: "If the actual argument corresponding to an assumed-type dummy argument is of a type with default-initialized components, or of a type that has has components that have the ALLOCATABLE or POINTER attributes, or are of types with default-initialized components, the assumed-type entity shall not have the INTENT(OUT) attribute." I also feel that the lack of any such restrictions on INTENT(INOUT) or no INTENT is very confusing, and will be misunderstood by some readers who were not involved in the discussions; the following is a draft of a note that might clarify the intent. "NOTE 5.3 The purpose of assumed-type is to allow companion processors to handle Fortran variables with arbitrary, but simple, types as raw data or raw storage. All uses of it will be processor dependent, and uses incompatible with Fortran syntax or semantics will be undefined." (B) Page 10, C1255 and C516. Reinhold Bader's point (H) explains that this has similar, though probably simpler, forms of the same problem, and I remain concerned about polymorphic types. I believe that the restriction should be that all non-assumed-type dummy arguments to BIND(C) procedures should be of interoperable type, and interoperable except that they are allowed the ALLOCATABLE or POINTER attributes,or are of assumed shape, type or character length. No wording is provided, though John Reid has posted a possibility on the WG5 reflector. (C) Page 20, 8.3.4 paragraph 8 and page 31, 8.7 paragraph 5. This should also exclude components with type parameters, type-bound procedures, final subroutines and possibly default-initialized components and polymorphic types. (D) Page 14 6.4.3. This does not describe the case of no DIM argument for UBOUND. Better wording would be: The description of the intrinsic function UBOUND in ISO/IEC 1539-1:2010 is changed for an assumed-rank object that is associated with an assumed-size array; if DIM is present and equal to the rank of ARRAY, the result of UBOUND(ARRAY,DIM,KIND) has a value equal to LBOUND(ARRAY,DIM,KIND)-2 with KIND omitted from LBOUND if it was omitted from UBOUND; if DIM is not present, the element RANK(ARRAY) of the result vector has a value equal to LBOUND(ARRAY,DIM,KIND)-2. (E) Passim. The term used in the standard is "final subroutine", not "final procedure". This should be changed. (F) 8.3.3 elem_len. Kind is not a C concept. "and kind" should be removed. _______________________________________________________________________ John Reid: 3) No, for the following reasons. Page 9, C407a. After "that" add "does not have INTENT(OUT) and". Reason: INTENT(OUT) causes the dummy argument to become undefined, so is a sort of assignment. Allowing it is inconsistent with C407b - the intention is that as assumed-type object be altered only by a C function. Page 10, C1255, line 2, change "or" to ", a variable that has the ALLOCATABLE or POINTER attribute, a variable of assumed shape, a variable of assumed type, a variable of assumed character length, or". Reason: We are currently saying that all these variables are disallowed as arguments of a procedure with the BIND attribute. This is at variance with the whole intent of the TS. This change perhaps goes too far. It allows a procedure to have the BIND attribute despite it being impossible to write a C function prototype with which it interoperates. If this is felt to be important, more constraints along the lines of C516 could be added. Page 17, 8.2, line 3 and page 20, end of para under Table 8.1. Change "scalar or is an assumed-shape, explicit-shape, or assumed-size array" to "scalar, an array whose shape is known, or an assumed-size array" or "an object whose shape is known or an assumed-size array." Reason: The present wording excludes the case of an actual argument of assumed rank. It is also misleading since there is nothing in the descriptor to distinguish an assumed-shape array from an explicit-shape array (and no need for it). In addition, I suggest this change: Page 15, RANK. In the Example para, change "effective" to "actual". Reason: The meaning is the same in this case, but the reader has to think it through with "effective". _______________________________________________________________________ --------------070003050001070204090306--