From owner-sc22wg5@open-std.org Sat Dec 4 23:12:18 2010 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id AEE6EC3BA06; Sat, 4 Dec 2010 23:12:18 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 900 seconds by postgrey-1.18 at www2.open-std.org; Sat, 04 Dec 2010 23:12:17 CET Received: from mailrelay2.lrz-muenchen.de (mailrelay2.lrz-muenchen.de [129.187.254.102]) by www2.open-std.org (Postfix) with ESMTP id AA2BDC3BA03 for ; Sat, 4 Dec 2010 23:12:17 +0100 (CET) Received: from webmail.lrz.de ([129.187.254.85] [129.187.254.85]) by mailout.lrz-muenchen.de with ESMTP for sc22wg5@open-std.org; Sat, 4 Dec 2010 22:56:34 +0100 Received: from p579d0b79.dip.t-dialin.net ([87.157.11.121]) (SquirrelMail authenticated user a2832ba) by webmail.lrz.de with HTTP; Sat, 4 Dec 2010 22:56:34 +0100 (CET) Message-Id: <40037.87.157.11.121.1291499794.squirrel@webmail.lrz.de> In-Reply-To: <20101108175805.5B97EC178E5@www2.open-std.org> References: <20101108175805.5B97EC178E5@www2.open-std.org> Date: Sat, 4 Dec 2010 22:56:34 +0100 (CET) Subject: Re: (SC22WG5.4350) WG5 informal ballot re Interop. TR From: Reinhold.Bader@lrz.de To: sc22wg5@open-std.org User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20101204225634_69873" Sender: owner-sc22wg5@open-std.org Precedence: bulk ------=_20101204225634_69873 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hello WG5, attached please find my answer to the informal ballot. Regards Reinhold > Dear WG5, > > Please find attached a WG5 informal ballot on the schedule and draft of TR > 29113. I hope it is self-explanatory. I will send the papers that it > references, > N1838/9, separately. > > I hope that members will engage in a lively email debate on the Interop TR > issues that concern them. It would be helpful if a ballot comment provides > a > summary and conclusion for each such debate. > > In addition, I am sure that J3 would welcome draft J3 papers that address > the > Unresolved Technical Issues (UTIs) in N1838. > > With best wishes, > > John. > ------=_20101204225634_69873 Content-Type: text/plain; name="informal_ballot_comments.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="informal_ballot_comments.txt" Formal WG5 ballot on TR29113: Answers and comments on N1838 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Is the above revised schedule acceptable? Yes. 2. Do you have any comments on N1838? Please give special attention to the UTIs. For each significant change, please provide text for a new UTI. Yes, see below for details. ========================================================================= 5.2.2: ~~~~~~ The definition of the member dim[] of CFI_cdesc_t mentions a "corresponding dimension" of the object without actually defining how this correspondence is set up. Presumably the zeroth element of dim corresponds to the first dimension in Fortran. Or is it the last? At the very least, a NOTE should be provided so C programmers do not get confused. 5.2.3: ~~~~~~ (a) UTI TR3: I agree with the argument that the rank field should match the return value of the RANK intrinsic. Of the contenders, I favor "(2) add an additional character length member" (this avoids contradictions with the definition of the elem_len member in 5.2.2, a change to which would be needed if (1) is adopted). (b) Changes in wording: para 3: Replace "the member attribute shall be" by "the member attribute shall have the value" para 3: Replace "member dim is equal to" by "member dim shall be equal to" 5.2.6.1: ~~~~~~~~ Suggested wording fix: In para 1, replace "for use in C functions" by "for invocation from C". 5.2.6.x: ~~~~~~~~ For the functions returning an integer value, the sentence "The result is an error indicator" is a general statement and should be moved to before specific instances of errors are listed wherever that is the case (given the text in 5.2.6.1 para 3 the sentence might even be removed). 5.2.6.5 CFI_associate: ~~~~~~~~~~~~~~~~~~~~~~ (a) Possible UTI: The applicability to assumed-shape entities appears spurious, at least in the case the ultimate actual argument was created in Fortran, possibly as a non-dynamic entity. I suggest limiting the use of this function to associating an existing C memory area with a Fortran entity with the POINTER attribute, analogous to C_F_POINTER, but with the additional feature that the resulting Fortran pointer can be non-contiguous. Dynamic creation of memory for Fortran objects should always be done using CFI_allocate, or by explicitly invoking malloc previous to a call to CFI_associate. Furthermore, discussion of memory requirements should either be removed or quite generally refer to the information stored in the descriptor. (b) Typo: remove the comma in the prototype at: "void *, base_addr" 5.2.7: ~~~~~~ The first sentence of para 1 appears to be outdated. I suggest replacing "The base address ... assignment." by "The base address in the C descriptor for a Fortran pointer shall be only modified by execution of either the CFI_associate or CFI_allocate functions, by pointer association or nullification inside a Fortran procedure, or by deallocation inside a Fortran procedure if this is permissible as stated in 6.7.3.3 of ISO/IEC 1539-1:2010." Similarly, in para 3, the sentence "It is possible ... in a C descriptor." should be replaced by "It is possible to associate a memory area defined within C with a Fortran pointer in a C descriptor (5.2.6.5)." (this memory area need not have been generated by a call to malloc()). 5.2.8: ~~~~~~ Para 3 item (2)(a) implies that functions with results which are arrays of interoperable type with or without the POINTER or ALLOCATABLE attributes are not interoperable. N1820 does not mention this case at all (there are of course some other cases which are not covered, but this seems the most glaring omission). Was this intended or is it an oversight? 5.3: ~~~~ Is this really needed? The contents of 5.2.6.7 and 5.2.7 appear to me to be sufficient to ensure the desired semantics. A.1.1: ~~~~~~ In para 1, remove ", as a solution to the "-i8" compiler switch problem." Concerning the discussion on TYPE(*) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Aleks has already pointed out some shortcomings here. Given the example in A.2 I'd particularly like to know what a_desc->type will be if the calling Fortran code does CLASS(*), ALLOCATABLE :: A(:,:), ... ALLOCATE(INTEGER(C_INT) :: A(10, 10), ...) CALL elemental_mult(A, B, C) as opposed to INTEGER(C_INT) :: A(10, 10), ... CALL elemental_mult(A, B, C) Quite generally, the "type" member in CFI_cdesc_t appears to cause more confusion than provide actual type safety. For statically typed dummy arguments, the C programmer will not need the information in the descriptor, because it is already provided by the signature. For TYPE(*) there either is no access to type information at all (in the descriptorless case), or complete type information is limited to intrinsic types (i.e., two different derived types with same elem_len cannot be disambiguated at all via the information available in the descriptor). These limitations should be pointed out in a NOTE. The recommended usage pattern for non-dynamic TYPE(*) entities should be that the type information is explicitly provided by the programmer; an appropriate comment should also be added to the elemental_mult() example A.2. (TYPE(*) arguments with the POINTER or ALLOCATABLE attribute will need to be associated with ultimate CLASS(*) actual arguments given the type compatility rules). Furthermore, examples with object management inside C should be added to A.2 (using CFI_associate as well as CFI_allocate). ------=_20101204225634_69873--