From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Mar 19 06:02:26 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 5FB1E356854; Mon, 19 Mar 2012 06:02:26 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107]) by www.open-std.org (Postfix) with ESMTP id 896C135672F for ; Mon, 19 Mar 2012 06:02:25 +0100 (CET) Received: from 218-42-159-108.cust.bit-drive.ne.jp ([218.42.159.108] helo=Maru6) by ns.nag-j.co.jp with smtp (Exim 4.50) id 1S9Uib-0003Lp-Kw for sc22wg5@open-std.org; Mon, 19 Mar 2012 14:01:17 +0900 Message-ID: From: "Malcolm Cohen" To: "WG5" References: <20120219131214.268A1356998@www.open-std.org> In-Reply-To: <20120219131214.268A1356998@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4624) Informal WG5 ballot on new draft DTS Date: Mon, 19 Mar 2012 14:02:24 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0197_01CD05D8.E8F6DDE0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0197_01CD05D8.E8F6DDE0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit >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. No, for the following reasons. REASON: Too many technical and editorial problems remain in the document. Attached 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. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo. ------=_NextPart_000_0197_01CD05D8.E8F6DDE0 Content-Type: text/plain; format=flowed; name="mjc-cmts-1904.txt"; reply-type=original Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mjc-cmts-1904.txt" 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. ------=_NextPart_000_0197_01CD05D8.E8F6DDE0--