From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Nov 21 09:41:25 2011 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 981EA35692B; Mon, 21 Nov 2011 09:41:25 +0100 (CET) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1145 seconds by postgrey-1.34 at www5.open-std.org; Mon, 21 Nov 2011 09:41:20 CET Received: from acsinet14.oracle.com (acsinet14.oracle.com [141.146.126.236]) by www.open-std.org (Postfix) with ESMTP id 50383356637 for ; Mon, 21 Nov 2011 09:41:19 +0100 (CET) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet14.oracle.com (Switch-3.4.4/Switch-3.4.1) with ESMTP id pAL8MFGj030265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Nov 2011 08:22:16 GMT Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAL8MCQF026072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Nov 2011 08:22:13 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pAL8MBWg017176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Nov 2011 08:22:12 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pAL8M6OL011751 for ; Mon, 21 Nov 2011 02:22:06 -0600 Received: from [192.168.1.65] (/99.121.57.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Nov 2011 00:22:06 -0800 Message-ID: <4ECA0A11.3040007@oracle.com> Date: Mon, 21 Nov 2011 00:21:37 -0800 From: Robert Corbett User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sc22wg5@open-std.org Subject: WG5 vote on draft DTS for further interoperability with C Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4ECA0A35.004A,ss=1,re=0.000,fgs=0 Sender: owner-sc22wg5@open-std.org Precedence: bulk Please answer the following question "Are N1885 and N1866 ready for forwarding to SC22 as the DTS and the response to the PDTS ballot?" in one of these ways. 1) Yes. 2) Yes, but I recommend the following changes. 3) No, for the following reasons. 4) Abstain. ------------------------------- I vote 3) No, for the following reasons. ------------------------------------------ 5.4 ASYNCHRONOUS attribute My greatest concern is still Clause 5.4. A small point first. Clause 5.4.1 states that asynchronous communication is initiated and completed by procedures written in C. Clause 5.4.2 states that asynchronous communications occurs through the action of procedures "defined by means other than Fortran." Those statements are not equivalent. Furthermore, both statements exclude an important possibility, namely that a Fortran processor might provide nonstandard intrinsic procedures that perform asynchronous communications. The statement in paragraph one of Clause 5.4.2 that whether a procedure is an asynchronous communication initiation or completion procedure is "processor dependent" might be misleading. Malcolm asserted that a procedure either is or is not an asynchronous communication procedure is determined by the procedure. Until I saw Malcolm's e-mail, I thought the draft TS meant that the processor would recognize a set of routines as asynchronous communication procedures. Malcolm's interpretation makes more sense, but the current text seems ambiguous. I would like the "processor dependent" statement to be replaced by language that says that an asynchronous communication procedure is one that initiates and/or completes asynchronous communication. My last concern is that the text in the draft TS does not address the impact of Clause 5.4 on processors. Bill said that the Fortran 2008 standard does not address the impact of asynchronous I/O on processors. I concede that the normative text of the standard does not (and I consider that a defect), but Clause C.6.6 does describe the intended effect. If the normative text of the TS does not address the intended impact of asynchronous communications procedures, a note similar to C.6.6 should be provided for asynchronous communications procedures. I would like definitions of asynchronous initiation procedures and asynchronous completion procedures to be added to Clause 3 "Terms and definitions." ------------------------------ 8.3.2 CFI_dim_t I still think the extent field should be an unsigned type, not a signed type. I do not think the definition of CFI_index_t is adequate. I would be satisfied by a note added to the TS explaining that range of values of a CFI_index_t might not include all values of bounds and extents used by a Fortran program. ------------------------------ 8.3.4 Macros I agree with Van that a macro for an attribute code for scalars should be included in Table 8.1. If no such macro is provided, then the TS should state how scalars are to be handled. Bill said that a scalar should be given the attribute code CFI_attribute_unknown_size. The only way I see to derive that information from the existing text is by elimination. ------------------------------- Robert Corbett representing Oracle America