From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Jul 11 21:36:30 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 AB23735689E; Mon, 11 Jul 2011 21:36:30 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 900 seconds by postgrey-1.33 at www5.open-std.org; Mon, 11 Jul 2011 21:36:26 CEST Received: from mailrelay2.lrz-muenchen.de (mailrelay2.lrz-muenchen.de [129.187.254.102]) by www.open-std.org (Postfix) with ESMTP id 92A4B356884 for ; Mon, 11 Jul 2011 21:36:26 +0200 (CEST) Received: from postout1.mail.lrz.de ([10.156.6.18] [10.156.6.18]) by mailrelay2.lrz-muenchen.de with ESMTP for sc22wg5@open-std.org; Mon, 11 Jul 2011 21:21:07 +0200 Received: from BADWLRZ-SWHBT2.ads.mwn.de (BADWLRZ-SWHBT2.ads.mwn.de [IPv6:2001:4ca0:0:108::126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postout1.mail.lrz.de (Postfix) with ESMTPS id F2DA9AF9D9 for ; Mon, 11 Jul 2011 21:21:06 +0200 (CEST) Received: from BADWLRZ-SWMBX1.ads.mwn.de ([fe80::11b4:b130:c4e2:2d0e]) by BADWLRZ-SWHBT2.ads.mwn.de ([fe80::5951:9dc3:7b2b:14ba%14]) with mapi id 14.01.0289.001; Mon, 11 Jul 2011 21:21:06 +0200 From: "Bader, Reinhold" To: WG5 Subject: Ballot on N1866 Thread-Topic: Ballot on N1866 Thread-Index: Acw//656ybKjU6woR1mv2tWXHu0u5g== Date: Mon, 11 Jul 2011 19:21:06 +0000 Message-Id: <166ED263DF83324D9A3BA67FB6772B2B1EA44553@BADWLRZ-SWMBX1.ads.mwn.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.187.48.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk Please answer the following question "Is N1866 ready for forwarding =0A= to SC22 as the PDTR?" =0A= =0A= Answer: Yes, but I recommend the following changes.=0A= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= =0A= All suggested edits are against N1866.=0A= =0A= (1) The PDF still contains a /Title entry with the value 11-146r1, as=0A= well as a /Subject entry which appears inappropriate. This should=0A= be fixed in the LaTeX source to say "TR29113" and "Type 2 =0A= Technical Report on Interoperability with C", respectively.=0A= =0A= (2) [v, para 6] After "Procedure", add "s" (Clause 3 has its heading=0A= correct)=0A= =0A= (3) [9:9] Remove the "s" at the end of "Arguments" (there is only =0A= one). =0A= =0A= (4) [11:15-16] Move line break to before CFI_=0A= =0A= (5) [11:25] Before "CFI_", insert "with "=0A= =0A= (6) [12:12,14] Replace "equals" with "is equal to", twice; this =0A= appears more consistent with later wording.=0A= =0A= (7) [12:40] Replace "In a descriptor ... array" by "In a C descriptor =0A= whose attribute member has the value CFI_attribute_unknown_size,"=0A= Reason: It is already explained elsewhere [14:2] what the =0A= attribute value means.=0A= =0A= (8) Looking at NOTE 5.3 I find I dislike it. It should, if present at=0A= all, rather point out what the general procedure on usage of the=0A= macro is. Here is a suggested replacement text:=0A= =0A= "NOTE 5.3=0A= The CFI_CDESC_T macro is provided to support management of objects=0A= suitable for use in Fortran within C, in particular by providing=0A= the memory needed for the C descriptor itself.=0A= The address of an entity declared using the macro is not =0A= usable as an actual argument corresponding to a formal parameter =0A= of type *CFI_cdesc_t without an explicit cast."=0A= =0A= (Notes 5.7 and 5.8 give further information which therefore =0A= needs no coverage here). =0A= =0A= (9) Table 5.3 contains two error code macros, CFI_INVALID_EXTENT and=0A= CFI_INVALID_SM which appear to be superfluous because no arguments=0A= of type CFI_dim_t appear in the API any more. I therefore suggest =0A= to delete these two error codes, and correct the description of=0A= CFI_ERROR_OUT_OF_BOUNDS by replacing the text "A reference is out=0A= of bounds" by=0A= "A function argument is causing out-of-bounds references"=0A= =0A= Quite generally, the description of the error codes refers to the=0A= C descriptor instead of the function argument; this appears=0A= inappropriate or at least incomplete for some of them.=0A= =0A= (10) [16:21,22] After "allocatable" and "pointer" respectively, add=0A= "variable".=0A= =0A= (11) [17:27] After "dummy" add "=3D0" to suppress compiler grumble.=0A= =0A= (12) In the description of CFI_establish, we've unfortunately omitted=0A= the effect on the lower bounds if an associated pointer is =0A= established. Suggested edit:=0A= [18:34] after "contiguous array" add "; if the attribute argument =0A= has the value CFI_attribute_pointer, the lower bounds of the object = =0A= described by /dv/ are set to zero"=0A= =0A= (13) In NOTE 5.7, replace "the descriptor" by "a descriptor"=0A= =0A= (14) NOTE 5.10 is not entirely correct. If the object is an unallocated=0A= allocatable variable, it appears to be processor dependent whether=0A= the object is contiguous.=0A= Suggested edit: Replace "or CFI_attribute_allocatable" by ", or =0A= which describes an allocated allocatable variable"=0A= =0A= (15) [21:5] Replace "source->dim[0].upper_bound" by=0A= "source->dim[0].lower_bound+source->dim[0].extent-1"=0A= (an upper_bound component does not exist)=0A= =0A= (16) [22:2] Replace "complex" by "_Complex"=0A= =0A= (17) [22:9] Replace "CFI_type_double_complex" by "CFI_type_double_Complex"= =0A= =0A= (18) [25:4] In "braces .", delete the blank.=0A= =0A= (19) [34:22/24] It seems inappropriate to introduce paragraphs 6 and 7 at = =0A= all in the places they are now. Suggestion: keep the whole section=0A= in para 5, and have para 6 start at [34:25].=0A= =0A= =0A= Regards=0A= Reinhold=0A= =0A= =0A=